why learn C?

[Flash Gordon]

arnuld wrote, On 23/02/07 08:19:

ok

Thank you.

Santosh addressed some of your points and gave answers I agree with, but
not, I think, all of then, and he snipped at least one bit I wanted to
respond to.

i guess, because it will help me in understanding all other languages
as C is the *hardest* language i have ever confronted.

Understanding algorithms does not help you understand languages, it
helps you do things with the languages you know.

Understanding Iambic Pentameter does not help you understand English and
French, but once you understand both Iambic Pentameter and English you
can write Iambic Pentameter in English, and if you understand German as
well you can write it in German.

> Assembly was
not that hard, Assembly is just *tedious*.

Assembly is not one language. There are many different assembly
languages, and I have done one that is IMHO an order of magnitude harder
than C and other that if you want to make it worth using assembler
rather than C (i.e. produce code that is faster/smaller/beter in
whatever measure) requires a lot more work than programming in C. For
example, in some assembly languages if you want to do any indirection at
all (including accessing a "variable" on the "stack") then you need to
use double indirection!

seems, like i am reading either OOD or Software Engineering concepts.
i think programming is different from Software Engineering.

What I described above applies whether you are using OOD/OOP or
developing a program in a pure functional language. It applies to safety
critical software of millions of lines and a 100 line hack program for
your own personal use. You might not always write down the results of
all of the above, and you might not do a thorough job on all of them,
and you might part way through one phase realise you have missed things
in an earlier phase. However, have you ever written a line of code
before deciding on the problem to be solved, even if the problem is only
how to display "Hello World!" on the screen (the analysis is, this
program must display "Hello World!")?

i knew that but "missing out things" made your explanation clear

If I did not say I was deliberately missing them then others would have
jumped in ;-)

so you are saying that i need to learn about algorithms in C++ too.
good idea i think

As Santosh said, you need to learn about algorithms. Saying you need to
learn about algorithms in C is like saying you need to learn about
physics in German. The programming language is merely what you use to
express your algorithms and design.

i never realised that. i always thought:

algorithms == maths != programming

An algorithm is a step by step method for solving a problem. Some
algorithms have a lot of maths, some do not. Here is an algorithm for
writing a sonnet:

1) Create an empty document in your word processor
2) Pick a number between 50 and 5000
3) Enter that number of random characters in to your word processor
4) If the word processors spell checker reports a mistake goto 1
5) If the word processors grammar checker reports an error goto 1
6) Get a girlfriend.
7) Read it to your girlfriend, and if she does not say "what a
wonderful sonnet" goto 1.

I will admit that it is not a very good algorithm, but it is a step by
step method for solving the problem and there is even a finite chance of
it working! Now, where is the maths in it?

i am not on a "team-lead".

I realised that, but the point was that what is most important for you
*now* depends on what you are doing, and later the most important thing
might change.

> i am just trying to learn OOD, C++ and STL
(for getting a job) and before that i want to become a good
programmer (like "pandit", the OP)

Well, none of those things are topical here ;-)

If you want to learn OOD/OOP I would start by reading a bit about OOA
(Object Oriented Analysis) which you will not fully understand, and for
a language pick something easier than C++. Even if you start by learning
the language, don't start with C++ start with an easier OO language.

this is how one learns C++, i have found.

Note that having learned one methodology (e.g. OO) and a programming
language that is targeted towards that methodology it is then easier to
learn other languages targeted towards the same methodology since you
only have to learn the language, not the language and the methodology.

this the 3rd post, from where i conclude that rather than working
randomly at different languages (like i usually do), one needs to
choose a language he likes and spend time practicing in it.

Yes, you definitely need to pick a language *and* a methodology and
stick with it until you get some experience with it and a reasonable
knowledge then move on to the next. If you do this and you are good you
will gradually find it easier to learn new methodologies and languages.

i also conclude, that you, "Flash Gordon", indirectly said that once
one becomes proficient in that language by practicing syntax,
algorithms and paradigms in his *favourite* language, then learning
other language becomes easier.

Yes. Especially languages targeting the same methodology. For example,
learning Java and OO properly should help learning C++. Learning Pascal
properly helps in learning C (the other way round applies as well). etc.

if i am RIGHT, then you have solved the biggest problem i am facing.

That's good, although this really belongs in a more general group such
as comp.programming

i am arnuld, nice to meet you ;-)

Have fun and one day you might be unlucky enough to work for me ;-)

 

[CBFalconer]

.... snip ...

I think of a procedural based language as being a language that allows
you to call a named subroutine (function, procedure, etc) like C,
Pascal, etc. Even Visual Basic Script from Microsoft is procedural
based using that description, but Basic wouldn't be (EX: gosub 1200).

Nonsense. That is just syntactical gubris. There are many
languages using the equivalent of "call routine". For example
Cobol uses PERFORM. IIRC Fortran uses CALL.

 

[user923005]

As to why learn C...
Because it is interesting and useful.

It is no different than "Why learn French?"
Or "Why learn calculus."

C is a good procedural language to learn because there is a good
market for this skill set.
C is a very useful language under the UNIX filter paradigm, where we
build small, simple tools and then chain their results together.
C is a mature language with a large installed base and a very complete
tool set.
Take a look at how many projects on SourceForge are written in C and
you will find that it is very popular.

If it is interesting to *you* to learn it then do it. If you would
rather learn something else, then learn something else instead.

 

[Charlton Wilbur]

dc> As to why learn C... Because it is interesting and useful.
dc> It is no different than "Why learn French?" Or "Why learn
dc> calculus."

But there are other reasons to learn French and calculus. I learned
Latin because it was interesting, but it was also useful; at the time,
there were a number of seicento treatises on music theory that I
wanted to read unfiltered. I'm sure that learning Sanskrit would have
been equally interesting (and possibly more interesting), but it would
have been nearly as practical.

In my case, I learned C because I was taking a data structures course
and did not want to deal with my lab partner. The course was taught
in Pascal, but the professor was happy to accept C so long as it would
compile and run on the system he happened to be using at the time.[1]
(I later realized this was a ploy to get me to write portable code.
Fortunately, he didn't have a DS9000.) Its usefulness at getting the
computer to do what I want was secondary at best.

Most of my day-to-day work is done in Perl or Objective-C, and somehow
the language-lawyery skills I developed in learning C have made me the
go-to person in this office for strictly conforming (X)HTML and CSS.

dc> If it is interesting to *you* to learn it then do it. If you
dc> would rather learn something else, then learn something else
dc> instead.

I'd concur; if learning C doesn't interest you, don't do it. There
are far too many people in this industry who got into it because they
thought there was money in it; if that's the reason the OP is asking
about C, he'd be far better off learning VB.NET or C#.NET.

Charlton

 

[arnuld]

Understanding algorithms does not help you understand languages, it
helps you do things with the languages you know.

Understanding Iambic Pentameter does not help you understand English and
French, but once you understand both Iambic Pentameter and English you
can write Iambic Pentameter in English, and if you understand German as
well you can write it in German.



Assembly is not one language. There are many different assembly
languages, and I have done one that is IMHO an order of magnitude harder
than C and other that if you want to make it worth using assembler
rather than C (i.e. produce code that is faster/smaller/beter in
whatever measure) requires a lot more work than programming in C. For
example, in some assembly languages if you want to do any indirection at
all (including accessing a "variable" on the "stack") then you need to
use double indirection!



What I described above applies whether you are using OOD/OOP or
developing a program in a pure functional language. It applies to safety
critical software of millions of lines and a 100 line hack program for
your own personal use. You might not always write down the results of
all of the above, and you might not do a thorough job on all of them,
and you might part way through one phase realise you have missed things
in an earlier phase. However, have you ever written a line of code
before deciding on the problem to be solved, even if the problem is only
how to display "Hello World!" on the screen (the analysis is, this
program must display "Hello World!")?

before reading your reply, i have always done exercises from the books
without any analysis of the problem. i just sit down and started to
code. i just read the statement. that's how i did programming. but now
your reply was *painful* and it is good because *growth* always equals
the amount of pain, 2 points:

1. Understanding algorithms does not help you understand languages, it
helps you do things with the languages you know.

2. i was in zero analysis zone, i never analysed problems.

i did know about point 1, but i must admit, i was not aware enough.
you did hit the point.

An algorithm is a step by step method for solving a problem. Some
algorithms have a lot of maths, some do not. Here is an algorithm for
writing a sonnet:

1) Create an empty document in your word processor
2) Pick a number between 50 and 5000
3) Enter that number of random characters in to your word processor
4) If the word processors spell checker reports a mistake goto 1
5) If the word processors grammar checker reports an error goto 1
6) Get a girlfriend.
7) Read it to your girlfriend, and if she does not say "what a
wonderful sonnet" goto 1.

ok, i want step 6 to happen first

;-)

I will admit that it is not a very good algorithm, but it is a step by
step method for solving the problem and there is even a finite chance of
it working! Now, where is the maths in it?

nowhere, to me, it is just a general idea of solving a problem. the
difference is you have written it step-by-step, in a clear manner.

Note that having learned one methodology (e.g. OO) and a programming
language that is targeted towards that methodology it is then easier to
learn other languages targeted towards the same methodology since you
only have to learn the language, not the language and the methodology.

Yes, you definitely need to pick a language *and* a methodology and
stick with it until you get some experience with it and a reasonable
knowledge then move on to the next. If you do this and you are good you
will gradually find it easier to learn new methodologies and languages.

ok i have decided that i will not go with OOD first:

1. will go with a general language like OCaml, C or Haskell.
2. will get a grip on that language's data structures
3. then will create algorithms in that language

then i will attempt OOD and a simpler language like Eiffell or Obj-C.
right now i am putting emphasis on learning algorithms.

i am not sure, as i will Google for my choices but in step 1, i guess,
C will win because it is used just like English. that is a big
advantage.

Yes. Especially languages targeting the same methodology. For example,
learning Java and OO properly should help learning C++. Learning Pascal
properly helps in learning C (the other way round applies as well). etc.


That's good, although this really belongs in a more general group such
as comp.programming

i know, that is why, "pandit" moved this post to "comp.programming"
but this thread remained active here. i also posted on same thread in
"comp.programming"

Have fun and one day you might be unlucky enough to work for me ;-)

[OT]
you are a Manager or a Businessman ?
[/OT]

-- arnuld
http://arnuld.blogspot.com

 

[Malcolm McLean]

However, have you ever written a line of code before deciding on the
problem to be solved, even if the problem is only how to display "Hello
World!" on the screen (the analysis is, this program must display "Hello
World!")?

This is a common fallacy.

In fact you can make bricks and bolts and other components even if you have
only the faintest idea you will biuld eventually.

For instance if you go to my website you will find code to load a tree in
Newick format. Though the format was devised for phylogenetic trees, in fact
it can be used to save virtually any tree. Anyone can use that component.

 

[Flash Gordon]

Malcolm McLean wrote, On 24/02/07 10:01:

This is a common fallacy.

In fact you can make bricks and bolts and other components even if you
have only the faintest idea you will biuld eventually.

You have done enough analysis to know that you need bricks and bolts
rather than sheets of paper and paper clips.

For instance if you go to my website you will find code to load a tree
in Newick format. Though the format was devised for phylogenetic trees,
in fact it can be used to save virtually any tree. Anyone can use that
component.

It all occurs at multiple levels.

Problem: people need to sort things
Analysis:Looking around a lot of what they want to sort is in arrays but
what they want to sort on varies drastically so the comparison routine
will have to be supplied by the user
Algorithm: Either selected from a book of a new sorting algorithm developed
Design: Specifying interfaces in detail, definition of how the algorithm
can be implemented
Coding: qsort implementation is written (this being about the time qsort
is added to the standard C library ;-)

Some times one of the phases is very short (maybe only 10 seconds), for
example when you already know the problem space well (or you do a bit of
looking and find Malcolm as done some tree code you can just lift, so
you decide to use his algorithm & code instead of your own). Sometimes
you add in additional constraints, such as I think this could be
generally useful, so lets extract it out in to a library and make it
nice and generic.

Often, particularly on small or home projects, a lot of the phases are
not written down. Sometimes there is a lot of overlap. Sometimes what I
consider to be algorithm work someone else might consider to be design.

Anyway, as I said in my initial post I was simplifying. Get those new to
SW development in to good habits then later they can learn when/where to
take short cuts.

 

[Flash Gordon]

arnuld wrote, On 24/02/07 08:52:

before reading your reply, i have always done exercises from the books
without any analysis of the problem. i just sit down and started to
code. i just read the statement. that's how i did programming.

You decided how to write the program didn't you?

Anyway, as I said else thread sometimes things are overlapped, sometimes
a given phase (particularly for the size of problem you have solved) is
very short. Often, the writer of the problem has effectively done the
analysis and maybe even algorithm and design worn.

> but now
your reply was *painful* and it is good because *growth* always equals
the amount of pain, 2 points:

1. Understanding algorithms does not help you understand languages, it
helps you do things with the languages you know.

2. i was in zero analysis zone, i never analysed problems.

i did know about point 1, but i must admit, i was not aware enough.
you did hit the point.

In my opinion a lot of it is more awareness of what you do without
thinking so that when the problem is big enough to warrant it you can
concentrate on one part of the process at a time.

ok, i want step 6 to happen first

;-)

Doesn't approximately 50% of the population at some point in their life

nowhere, to me, it is just a general idea of solving a problem. the
difference is you have written it step-by-step, in a clear manner.

That is the essence of a lot of analysis, algorithm development, design
and coding. You are just concentrating on it at different levels.

ok i have decided that i will not go with OOD first:

1. will go with a general language like OCaml, C or Haskell.
2. will get a grip on that language's data structures
3. then will create algorithms in that language

then i will attempt OOD and a simpler language like Eiffell or Obj-C.
right now i am putting emphasis on learning algorithms.

i am not sure, as i will Google for my choices but in step 1, i guess,
C will win because it is used just like English. that is a big
advantage.

C is both a good and a bad language, and sometimes the reason it is good
is also the reason it is bad. I started with Basic because that was what
was available to me, you have the choice. You also seem to have the most
important thing which is the desire to learn. Another advantage of C is
this group. When you have tried to solve a problem post your attempt
here (even if you think is is perfect and you have nothing more to learn
from it) and you will get expert advice on what you have done, sometimes
alternative methods to solve the same problem, and all this gives you a
learn a vast amount more. You will get such advice even if it is a
something you might think we would consider far to simple to bother
with, because a lot of people actually enjoy helping others get a start.

i know, that is why, "pandit" moved this post to "comp.programming"
but this thread remained active here. i also posted on same thread in
"comp.programming"

OK. I will leave it here.

Have fun and one day you might be unlucky enough to work for me ;-)

[OT]
you are a Manager or a Businessman ?
[/OT]

I am professional SW developer / geek / occasional consultant /
technical authority / IT JOAT[1]. In the past I have had fresh graduates
working at least half for me.

[1] Jack Of All Trades.

 

[Malcolm McLean]

Malcolm McLean wrote, On 24/02/07 10:01:

Anyway, as I said in my initial post I was simplifying. Get those new to
SW development in to good habits then later they can learn when/where to
take short cuts.

The problem is that a lot of formal methods do more harm than good. Some can
have a devastating effect on productivity, and there is not a single example
of a "formal method", as opposed to a "programming paradigm" that has been
proved to reduce costs or improve quality over a range of projects.

In fact you often get the irony of professors writingsolemn treatises on
software engineering on wordprocessors and operating systems not built
according to the principles they are advocating.

However the answer is not to say "therefore I have no interest in such
things". Programming is quite a new discipline and the capabilites of the
hardware currently exceed our ability to manage the software. However
answers will be found.

 

[Flash Gordon]

Malcolm McLean wrote, On 24/02/07 21:39:

The problem is that a lot of formal methods do more harm than good.

I was not advocating formal methods. Of course, you might mean something
different to me when referring to formal methods. I've not checked it
carefully, but Wiki-pedia has some info about what I mean by formal
methods here http://en.wikipedia.org/wiki/Formal_methods

Since I was not advocating formal methods, what makes you think problems
with formal methods are relevant to what I posted?

> Some
can have a devastating effect on productivity, and there is not a single
example of a "formal method", as opposed to a "programming paradigm"
that has been proved to reduce costs or improve quality over a range of
projects.

Well, I was not advocating formal methods so I don't know why you have
brought them up as being a problem in reference to what I said.

In fact you often get the irony of professors writingsolemn treatises on
software engineering on wordprocessors and operating systems not built
according to the principles they are advocating.

In general formal methods and the like are targeted more towards safety
critical stuff where you want it provably correct so that you can prove
your SW will not lead to a death.

However the answer is not to say "therefore I have no interest in such
things". Programming is quite a new discipline and the capabilites of
the hardware currently exceed our ability to manage the software.
However answers will be found.

Where I used to work the simple stuff I was suggesting (which is not
formal methods) is applied first at the system level, then once it has
been decided what will be implemented in HW, what in SW, what in
mechanical engineering (e.g. safety cut-outs), what in optics (yes,
sometime something can be implemented in optics or a mix of mechanics
and SW) etc you then go through requirements analysis, algorithm
development, design and implementation in all of the engineering
disciplines, not just SW.

Most of the time where I have worked you do not produce an algorithms
document I will admit, since most of the time you mostly use "off the
shelf" algorithms.

 

[Malcolm McLean]

Malcolm McLean wrote, On 24/02/07 21:39:

I was not advocating formal methods. Of course, you might mean something
different to me when referring to formal methods. I've not checked it
carefully, but Wiki-pedia has some info about what I mean by formal
methods here http://en.wikipedia.org/wiki/Formal_methods

I was using the term more in the sense of "lightweight formal methods" used
in the Wiki. That is to say, management procedures designed to reduce errors
rather than mathematical proofs of algorithm correctness.

In practise the two merge together, though I suspect a lot of the confusion
arises from mangers trying to imply that they are formally proving
algorithms when they aren't.

 

[Chris Dollin]

At about the time of 2/23/2007 4:19 AM, Chris Dollin stated the following:

Hmmm...

I think of a procedural based language as being a language that allows
you to call a named subroutine (function, procedure, etc) like C,
Pascal, etc. Even Visual Basic Script from Microsoft is procedural
based using that description, but Basic wouldn't be (EX: gosub 1200).

(The Basic I'm most used to has PROCedures and FuNctions, and anyone
who used GOSUB in it would have been mad in at least three different
ways.)

About the only language I can think off off-hand which isn't
procedural by your definition is SQL, since Prolog has named
clauses, Haskell has functions, and Java/Smalltalk/Ruby have
methods.

I am curious as to what languages you think aren't procedural,
but since I'm definitely off-topic, I'll stop without asking.

 

[Chris Barts]

Nonsense. That is just syntactical gubris. There are many
languages using the equivalent of "call routine". For example
Cobol uses PERFORM. IIRC Fortran uses CALL.

Local variables are the dividing line between procedural and non-procedural
languages, then. You can emulate them (increasingly badly) in 'classic'
microcomputer BASIC dialects (GW-BASIC), COBOL, and ancient microcomputer
BASIC dialects (Tiny BASIC). However, not being able to completely hide
locals cripples robustness and code reuse.

 

[Marc Boyer]

Once you learn an algorithm and try implementing it once, you should
be able to reimplement in another language, without having to relearn
the algorithm itself, since it's just pure logic. The devil is in the
details however.

Yes.
Insertion in a sorted linked list is not the same job in Lisp
or C.

Marc Boyer

 

[Malcolm McLean]

(The Basic I'm most used to has PROCedures and FuNctions, and anyone
who used GOSUB in it would have been mad in at least three different
ways.)

Gosub is so useless that I didn't even provide it in MiniBASIC.
BASICdraw() now has a CALL in response to criticisms, but it introduces lots
of problems.

I am curious as to what languages you think aren't procedural,
but since I'm definitely off-topic, I'll stop without asking.

I think that leads to the question of what is a programming language.
Theoretically you can say that anything that can emulate a Turing machine is
a language, but in practise that isn't too helpful a definition.