which language i should learn, ( to learn algorithms and software design ) ?
pandit
i want to become a good programmer. one of my friends ( named
"arnuld", he posts here infrequently), taught me Lisp. so i am not a
programming beginner.
i have heard these 2 points. i want to know how :
1. C gives you a strong base of Procedural style of programming which
forms the basis of learning other paradigms e.g OOP
2. with C one will learn about pointers and algorithms.
3. /arnuld/ told me this in an email:
" i think algorithms and data-structures are more important than
learning a new programming language . Hence i prefer learning about
algorithms and data structures 1st, before i attempt a new programming
language or paradigm like OOD. i think that is a better way. i said so
after
searching the archives of "comp.programming", "comp.lang.c++",
"comp.lang.c" & "comp.lang.lisp" , at these places i found that
learning about programming, algorithms, data structures, abstraction,
software design and problem solving, and version control is much more
important and time consuming than simply learning a language, almost
all folks agree on that learning a programing language is a simple
task as compared to what they have described here"
/arnuld/ is not an experienced programmer, so i feel difficulty in
believing his words.
- pandit
- pandit
santosh
> hai all,
>
> i want to become a good programmer. one of my friends ( named
> "arnuld", he posts here infrequently), taught me Lisp. so i am not a
> programming beginner.
>
> i have heard these 2 points. i want to know how :
>
> 1. C gives you a strong base of Procedural style of programming which
> forms the basis of learning other paradigms e.g OOP
Not quite. Functional and declarative programming are radically
different from the procedural style. In such cases learning a
procedural language will not gain you much. However for C
"derivatives" like C++, Java etc., prior C knowledge will certainly be
useful.
> 2. with C one will learn about pointers and algorithms.
You can learn both of the above with other languages as well,
certainly the latter. Some languages don't support pointers or provide
a crippled version of them.
> 3. /arnuld/ told me this in an email:
>
> " i think algorithms and data-structures are more important than
> learning a new programming language . Hence i prefer learning about
> algorithms and data structures 1st, before i attempt a new programming
> language or paradigm like OOD. i think that is a better way. i said so
> after
> searching the archives of "comp.programming", "comp.lang.c++",
> "comp.lang.c" & "comp.lang.lisp" , at these places i found that
> learning about programming, algorithms, data structures, abstraction,
> software design and problem solving, and version control is much more
> important and time consuming than simply learning a language, almost
> all folks agree on that learning a programing language is a simple
> task as compared to what they have described here"
>
> /arnuld/ is not an experienced programmer, so i feel difficulty in
> believing his words.
The theoretics of algorithms, abstraction, system design etc. are
indeed language independant. But to get a good grasp of anything
you'll have to put the theory to practise. For that you need to choose
a particular language, (or a collection of languages), and a set of
tools. Each language or tool employs certain tradeoffs; in striving to
make one aspect of software easier, other aspects may be made more
obtuse. That's reality.
Even if a language happens to "perfect", it's environment and
interaction with other systems will not be.
The poster you've quoted is roughly correct. Acquiring the skills of
good programming is more difficult and time consuming than picking up
a language, but the latter is a practical necessity for the former.
Michael
There are four major programming paradigms:
1) Procedural
Pascal, C, Ada, Fortran
2) OO
Java, C++, Smalltalk
3) Functional
LISP, ML
4) Declarative
Prolog, SQL, Makefiles
If you knew Pascal and wondered whether you should learn C or study
data structures and algorithms, I'd definitely say the latter. But
the four paradigms are very different, so when you learn data
structures and algorithms in each, you think about things differently.
But yes, there definitely is a lot of knowledge that is language
independent. Other than the obvious data structures and algorithms,
I'd add recursion, iteration, control flow, testing, source control,
requirements gathering, debugging, profiling, and probably many others
if I thought about it.
One thing C has going for it is that it's very close to the hardware.
So you'll learn about how computers actually work (e.g., pointers),
rather than something very abstracted away from the actual details.
This will help you later in life if you ever need to do low-level
programming (embedded or OS, for example), and probably even to
optimize high-level stuff, because you'll understand the fundamentals.
The other point I'd have is that, although it is possible, I've never
seen LISP programs that make heavy use of iteration. 'While' loops
and 'for' loops are very common in procedural and OO programs, and
knowing how to write one is very important, but most LISP programs
solve the problems a different way. So I'd almost recommend C just
for that feature.
Michael
Hallvard B Furuseth
> i have heard these 2 points. i want to know how :
>
> 1. C gives you a strong base of Procedural style of programming which
> forms the basis of learning other paradigms e.g OOP
Nah, not beyond showing you some of the things that C lacks but Lisp
has. Like real macros, lambdas and closures. You already know Lisp,
and you can write procedural programs just fine in Lisp.
> 2. with C one will learn about pointers and algorithms.
Pointers, yes. Algorithms? Maybe what is meant is that with C you'll
get closer to the nuts and bolts of the computer, and that's important.
For that reason I think it's a good idea to learn C next. You need to
worry about many things in C which Lisp takes care of or protects you
from - memory management, buffer overruns (storing data past the end of
an array), more careful error checking.
> 3. /arnuld/ told me this in an email:
>
> " i think algorithms and data-structures are more important than
> learning a new programming language . Hence i prefer learning about
> algorithms and data structures 1st, before i attempt a new programming
> language or paradigm like OOD.
Yup. You need to learn some different languages, learning a bunch of
languages doesn't by itself make you a good programmer any more than
learning to use pen and paper makes you a good author.
> i think that is a better way. i said so after
> searching the archives of "comp.programming", "comp.lang.c++",
> "comp.lang.c" & "comp.lang.lisp" , at these places i found that
> learning about programming, algorithms, data structures, abstraction,
> software design and problem solving, and version control is much more
> important and time consuming than simply learning a language, almost
> all folks agree on that learning a programing language is a simple
> task as compared to what they have described here"
In short, it takes a long time to become a good programmer. You won't
get away with just learning the easy part. (Which is not unique to
programming.)
Notice the "compared to" in the last line though. Learning the basics
of a programming language can take relatively short time, but learning
its full capabilities and problems and to use it well takes much longer.
--
Regards,
Hallvard
Beliavsky
<snip>
> There are four major programming paradigms:
> 1) Procedural
> Pascal, C, Ada,Fortran
> 2) OO
> Java, C++, Smalltalk
> 3) Functional
> LISP, ML
> 4) Declarative
> Prolog, SQL, Makefiles
Python is a nice, modern, interpreted language and supports the first
3 paradigms listed. I recommend it. I don't know enough about paradigm
(4) to comment on it.
<snip>
jimmaure...@worldnet.att.net
Ada is just as OO as C++, while C++ is just as procedural as Ada.
On the other hand, Ada and Java and C# provide built-in syntax for
concurrency.
Given the processor trend for more and more CPU cores, concurrency is
becoming a much more important feature in a language.
Studying concurrency will also provide you with the opportunity to
deal with
race conditions, deadlocks, priority issues, and other issues dealing
with the differences between synchronous and asynchronous designs.
Jim Roges
pandit
> indeed language independant. But to get a good grasp of anything
> you'll have to put the theory to practise. For that you need to choose
> a particular language, (or a collection of languages), and a set of
> tools. Each language or tool employs certain tradeoffs; in striving to
> make one aspect of software easier, other aspects may be made more
> obtuse. That's reality.
so you are saying:
i can choose whatever language i like and then start programming in
it ? and then i will learn the concepts from this language and i can
do the same in some X programing language. there will not be much
difference in both cases (except of syntax and paradigm-support)
right?
> The poster you've quoted is roughly correct. Acquiring the skills of
> good programming is more difficult and time consuming than picking up
> a language, but the latter is a practical necessity for the former.
i met "arnuld" last week. we meet quite infrequently. he is good guy
and supports Free Softwares. i remember he told me 1year ago that how
he threw away the 35 CDs of WIndows and Windows based software and he
said he will never use any non-free sofwtare on his PC. except this,
most of his behavioral characteristics exactly match the Hacker's way
of thinking, as described by ESR in:
http://catb.org/esr/jargon/html/appendixb.html
thanks
pandit
> > forms the basis of learning other paradigms e.g OOP
>
> Nah, not beyond showing you some of the things that C lacks but Lisp
> has. Like real macros, lambdas and closures. You already know Lisp,
> and you can write procedural programs just fine in Lisp.
so i guess, i can use any language.
- pandit
Friedrich Dominicus
>
> There are four major programming paradigms:
> 1) Procedural
> Pascal, C, Ada, Fortran
> 2) OO
> Java, C++, Smalltalk
> 3) Functional
> LISP, ML
> 4) Declarative
> Prolog, SQL, Makefiles
Well just a few comments.
Common Lisp hat th CLOS, nothing in it prevents you from using it
procedural also and through macros you you make it as declarative as
you like (as quite a few implementation of Prolog embedded in Common
Lisp show)
there are other "multipardigmen" Sprachen unter anderem
Mozart/Oz: http://www.mozart-oz.org/
Smalltalk surely is OO-ish however it does have closures and therfor
it can be used in a functinal fashion also.
There are extensions to either Pascal or C or Ada to make it suitable
for OO-programming.
>
> One thing C has going for it is that it's very close to the hardware.
> So you'll learn about how computers actually work (e.g., pointers),
AFAIKT Pascal has them also, and to get closer to the hardware the
choice should probably be Assembler
Languages you left out completly are the "scripting languages"
>
> The other point I'd have is that, although it is possible, I've never
> seen LISP programs that make heavy use of iteration.
Well then you do not have done any serious Lisp programming. Lisp
programs do make use of "iteration" as much as nearly any other
langauge. Common Lisp has at least 3 "iterative" loop constructs. And
you can even introduce new ones if you wish.
> 'While' loops
> and 'for' loops are very common in procedural and OO programs, and
> knowing how to write one is very important, but most LISP programs
> solve the problems a different way.
they may or may not. If you do not belive feel free to visit:
http://www.q-software-solutions.de/forum/viewtopic.php?t=2625
which might give you at least an idea
> So I'd almost recommend C just
> for that feature.
Well that is a very strange recommodation
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Muntasir Azam Khan
lot than just writing code. Learning about algorithms and data
structures and being able to think of problems and their solutions in
an abstract way, independent of the actual LISP/C code, is vital for
becoming a real programmer. When you can do that, learning new
languages is not very difficult. The solution to a problem is the
same, regardless of the language it is implemented in. But I think it
is also a good idea to learn as many languages as possible. This makes
you able to think in different ways, and makes you able to chose the
best language for each job. C is a great language to work with and, as
others have already pointed out, has several good things going for it
like generating fast executables and being the language understood by
most other programmers. I really benefited from my knowledge of C when
I learned Java, C++ and C# later. So, go ahead and learn C. But keep
studying about algorithms while you are at it.
CBFalconer
> "Michael" <mchl...@aol.com> writes:
>
... snip ...
>>
>> One thing C has going for it is that it's very close to the
>> hardware. So you'll learn about how computers actually work
>> (e.g., pointers),
>
> AFAIKT Pascal has them also, and to get closer to the hardware
> the choice should probably be Assembler
No. For example, it doesn't have the cavalier attitude to pointers
of C. This is a great advantage in generating correct code, and a
great disadvantage in direct machine access.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
santosh
Don't remove attributions.
> > The theoretics of algorithms, abstraction, system design etc. are
> > indeed language independant. But to get a good grasp of anything
> > you'll have to put the theory to practise. For that you need to choose
> > a particular language, (or a collection of languages), and a set of
> > tools. Each language or tool employs certain tradeoffs; in striving to
> > make one aspect of software easier, other aspects may be made more
> > obtuse. That's reality.
>
> so you are saying:
>
> i can choose whatever language i like and then start programming in
> it ? and then i will learn the concepts from this language and i can
> do the same in some X programing language. there will not be much
> difference in both cases (except of syntax and paradigm-support)
>
> right?
To express logic a language, or notation is needed. It could be a
practical programming language, a toy language, flowchart, anything. I
myself would recommend a usable language like C or C++. Once you got a
language to work with, you can express algorithms and try them out.
<snip>
> i met "arnuld" last week. we meet quite infrequently. he is good guy
<snip noise>
It's totally irrelevant who "arnuld" is or what he thinks.
arnuld
> To express logic a language, or notation is needed. It could be a
> practical programming language, a toy language, flowchart, anything. I
> myself would recommend a usable language like C or C++. Once you got a
> language to work with, you can express algorithms and try them out.
that is a very good & clear explanation. however regarding the choice
of language, i guess, i will go with OCaml, Haskell, Mercury or C.
i guess, C will win as it is used just like English. that is a big
advantage for anyone who aspires to become a good programmer and as i
have *noticed* that most programmers said to "newbies":
"solve the types of problems you can solve with your favourite
programming language."
i will choose my favourite now.
> > i met "arnuld" last week. we meet quite infrequently. he is good guy
>
> <snip noise>
>
> It's totally irrelevant who "arnuld" is or what he thinks.
[OT]
it is irrelevant but "pandit" is a USENET newbie, so i am sure, he
does not even know why i used those words inside the brackets.
[/OT]
pandit
> > 1. C gives you a strong base of Procedural style of programming which
> > forms the basis of learning other paradigms e.g OOP
>
> Not quite. Functional and declarative programming are radically
> different from the procedural style. In such cases learning a
> procedural language will not gain you much. However for C
> "derivatives" like C++, Java etc., prior C knowledge will certainly be
> useful.
i get this from "comp.object":
-----------------------------------------------------------------------------
There are assumptions that form the foundations of understanding. It
is how knowledge is constructed. All knowledge, all philosophy, is
based, at some point, on assumptions. One set of assumptions that we
make is the representation of logic, another is the representation of
information, and another is the process by which problems will be
solved. The last is often the most fundamental, in that it drives
much of the grammatical construction of the language itself. The Lisp
language assumes many things about the programmer, including an
inherent understanding of how to construct problems
in the form of lists, how to analyse data as lists, and how to express
solutions contrived from lists, including the list of programming
instructions themselves. The more typical von-neumann architecture
seperates data from instructions and assumes an approach not
dissimilar to the ones originally described by Aristotle. This
approach is the one we now refer to as functional decomposition and
forms the cornerstone of procedural software development. It is not
the cornerstone of functional programming or logic programming. The
language is an expression of the assumptions on which it is based.
Languages, inasmuch as they express thought, also mold it. It is far
easier to describe some problems in a particular language. The SQL
statement "SELECT row_id, type_code, type_name FROM tblTransactionType
where type_code = 'DBT'" is easy to express in SQL but would require
quite a few more lines of code to describe well in a procedural
language if the data were stored in a flat file. In the same sense
that some concepts are best explained in one language than another, it
is true that practitioners of a language will more quickly learn to
express elegant ideas that the language is suited for. In other
words, not only does the language affect the length of the expression,
it also affects the practitioner. That is why it is imperative that
new developers learn multiple languages, and nearly every college
teaching computing science endeavors to insure it.
If your start is in Lisp, cudos. However, the problems faced by
procedural developers are solved, at least partially, by OO
languages. Therefore, to truly understand these solutions, and
understand how they are elegant solutions to a particular set of
problems, you need to understand the problems. You need to understand
the procedural paradigm.
You cannot skip it.
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
-------------------------------------------------------------------------------------------------
any views on this?
-- pandit
Chris Barts
comp.programming <1172175372.0...@k78g2000cwa.googlegroups.com>:
> There are four major programming paradigms:
> 1) Procedural
> Pascal, C, Ada, Fortran
> 2) OO
> Java, C++, Smalltalk
> 3) Functional
> LISP, ML
> 4) Declarative
> Prolog, SQL, Makefiles
I'd add two big points to this:
1) You can make any language do almost anything, but you often lose
readability and concision if you make a language do something for which it
was not intended. How far a language can be pushed in any given direction
is how flexible that language is. Some languages (Lisp, C) are a lot more
flexible than others (Pascal, COBOL).
2) These paradigms not only merge into each other, with some languages
(Lisp, C++) straddling multiple paradigms without producing ugly code, but
they fragment into pieces on closer inspection, with Forth and Postscript
and other stack languages breaking off from Procedural and a huge rift
forming in Functional between Lisp-derived languages and ML-derived
languages. I'd also note that many OO languages are simply procedural
languages with an object system added on. Java, C++, Ada, and Visual Basic
all fit this pattern. In Common Lisp, the object system is written in the
language itself. Smalltalk is almost the other way around, a simple
Lisp-like language built on top of an object system. In other words, C++
and Java applied OO lessons to a C-like base; Ada applied them to a
Pascal-like base; Common Lisp used them to extend itself with itself;
Smalltalk was created to take a certain idea about OO as far as possible;
O'Caml (in the ML family with Haskell) used the ideas to extend an already
rich type ontology.
>
> If you knew Pascal and wondered whether you should learn C or study
> data structures and algorithms, I'd definitely say the latter. But
> the four paradigms are very different, so when you learn data
> structures and algorithms in each, you think about things differently.
Indeed. Going from Common Lisp to Haskell is a huge transition, even though
they are both Functional.
>
> But yes, there definitely is a lot of knowledge that is language
> independent. Other than the obvious data structures and algorithms,
> I'd add recursion, iteration, control flow, testing, source control,
> requirements gathering, debugging, profiling, and probably many others
> if I thought about it.
Recursion is dependent on finding a language that isn't horribly ancient.
Some languages designed to fit on hilariously tiny mainframes without
stacks can't express it. If you find a language designed after the Korean
War you'll probably be fine, however.
>
> One thing C has going for it is that it's very close to the hardware.
> So you'll learn about how computers actually work (e.g., pointers),
> rather than something very abstracted away from the actual details.
> This will help you later in life if you ever need to do low-level
> programming (embedded or OS, for example), and probably even to
> optimize high-level stuff, because you'll understand the fundamentals.
I've always been a big proponent of this theory as well. C has served well
as a portable assembly language for decades now.
>
> The other point I'd have is that, although it is possible, I've never
> seen LISP programs that make heavy use of iteration. 'While' loops
> and 'for' loops are very common in procedural and OO programs, and
> knowing how to write one is very important, but most LISP programs
> solve the problems a different way. So I'd almost recommend C just
> for that feature.
Heh. What did I say about most OO languages being Procedural in disguise?
Smalltalk has a similar way of doing away with explicit iteration.
>
> Michael
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.