why learn C?

[pandit]

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

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 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. i want to know the views of people here,a s much
of the post belong to C.
- pandit

[Marc Boyer]

Le 22-02-2007, pandit <ja*****@gmail.coma écrit*:

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

I am not sure that C gives better 'strong base' than Ada.

2. with C one will learn about pointers and algorithms.

pointers: yes
algorithms: why ?

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 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. i want to know the views of people here,a s much
of the post belong to C.

On algorithms: it depends what mean 'learning about algorithms'. In
every day programming, quick-sort is the most complicated algo I wrote,
ans, in all my programming life, the most complicated one was
implementing red-black tree. It is far away for beeing algorithm expert.
But some 'minimum' is needed (linked list, map, tree, sorting...).

The same, there is not a lot of every day *theoretical* structures:
array, lists, hash-map, tree...

Moreover, I do not know how to learn 'abstraction, software design and
problem solving' without any langage. Moreover, I am under the
impression that the 'good' software design is not langage-independant.

At leats, learning C is usefull because the is C, a kind of universal
programming langage known by all, a little bit like 'English' in
natural langages.
Marc Boyer

[santosh]

pandit wrote:

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

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 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. i want to know the views of people here,a s much
of the post belong to C.

Have you asked permission from "arnuld" to publicise his private
correspondences?

Since this seems to be a general question on learning programming or
rather software engineering, you'd get a much better response in
comp.programming than here. All I can say is that the third point
above by your "arnuld" is, when interpreted *very* liberally, right.

[arnuld]

1. C gives you a strong base of Procedural style of programming which

forms the basis of learning other paradigms e.g OOP

I am not sure that C gives better 'strong base' than Ada.

OK, 1st have to Google for Ada as i never came across some Ada-code. i
never even read about its design-goals and/or any articles related to
it.

BTW, your "summary of Ada" can be useful for me, if you can.

2. with C one will learn about pointers and algorithms.

pointers: yes
algorithms: why ?

why not ?

1. i tried some Common Lisp where i never had to worry about
algorithms.

2. in C++, you get read-made algorithms from Standard Library, so
around 95% of the times, you only need to do "#include<algorithm>".

whereas in C, you have design the algorithms, from scratch.

but may be i am biased, as i did not take the case of other languages
like OCaml, Haskell, Mercury or Eiffel here.

" i think algorithms and data-structures are more important than
learning a new programming language.

[SNIP]

/arnuld/ is not an experienced programmer, so i feel difficulty in
believing his words. i want to know the views of people here,a s much
of the post belong to C.

On algorithms: it depends what mean 'learning about algorithms'.

i meant, "applying the specific algorithm, in the language your are
working with".

[SNIP]
Moreover, I do not know how to learn 'abstraction, software design and
problem solving' without any langage.

you can't. what i meant is:

abstraction, software-design & problem-solving are independent of any
programming language *and* you learn all of these by applying them in
a programming language, just like algorithms."
i think that was obvious.

Moreover, I am under the
impression that the 'good' software design is not langage-independant.

good software design is language-independent,as i said already, *and*
some programming languages are a not a good-fit for a particular
design but a perfect-fit for some other designs.

At leats, learning C is usefull because the is C, a kind of universal
programming langage known by all, a little bit like 'English' in
natural langages.

Is this the only benefit you think of C (except pointers) ?

i guess, there are more.
BTW, thanks for the critique.

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

[arnuld]

Have you asked permission from "arnuld" to publicise his private

correspondences?

why he needs a permission from a person like me. check my BLOG on why
i said so.

BTW, the thoughts i wrote down are the *only* the interpretation, as
per my viewpoint, of the knowledge i have accumulated from the USENET.

Since this seems to be a general question on learning programming or
rather software engineering, you'd get a much better response in
comp.programming than here.

i guess, "pandit" must have taken your advice seriously.

All I can say is that the third point
above by your "arnuld" is, when interpreted *very* liberally, right.

Oh.. thanks Snatosh

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

[Marc Boyer]

Le 22-02-2007, arnuld <ge*********@gmail.coma écrit*:

1. C gives you a strong base of Procedural style of programming which
forms the basis of learning other paradigms e.g OOP

> I am not sure that C gives better 'strong base' than Ada.

OK, 1st have to Google for Ada as i never came across some Ada-code. i
never even read about its design-goals and/or any articles related to
it.

comp.lang.ada

BTW, your "summary of Ada" can be useful for me, if you can.

In a very few words, Ada is a modern Pascal. And Ada 83
is, to me, a very good langage to learn procedural programming.

2. with C one will learn about pointers and algorithms.

pointers: yes
algorithms: why ?

why not ?

This is the one that states somthing that have to give argument,
not the opposite.

1. i tried some Common Lisp where i never had to worry about
algorithms.

How ? How did you do a balanced binary tree in Common Lisp
without algorithm ?

2. in C++, you get read-made algorithms from Standard Library, so
around 95% of the times, you only need to do "#include<algorithm>".

whereas in C, you have design the algorithms, from scratch.

No, they are several ready-made library for C. One difference
with C++ is that you have to chose one, this is not in the
standard. But you also can do everything by yourself in C++.

but may be i am biased, as i did not take the case of other languages
like OCaml, Haskell, Mercury or Eiffel here.

And so many others...

>On algorithms: it depends what mean 'learning about algorithms'.

i meant, "applying the specific algorithm, in the language your are
working with".

There is a gap between writing and using. What did you mean by
'applying' ?

you can't. what i meant is:

abstraction, software-design & problem-solving are independent of any
programming language *and* you learn all of these by applying them in
a programming language, just like algorithms."

i think that was obvious.

No. The same problem is not solved the same way in SQL, Matlab, C or Prolog.
OK, the is a 'common base': clear interface, independant implementation,
and general enough but not too much.
But is there a way to learn it independantly from the langage?
I do not think so. I may be wrong.

>Moreover, I am under the
impression that the 'good' software design is not langage-independant.

good software design is language-independent,as i said already, *and*
some programming languages are a not a good-fit for a particular
design but a perfect-fit for some other designs.

yes and no. It is a long debate...

> At leats, learning C is usefull because the is C, a kind of universal
programming langage known by all, a little bit like 'English' in
natural langages.

Is this the only benefit you think of C (except pointers) ?

Benefit of 'learning' C or benefit of 'using' C ?

Marc Boyer

[santosh]

arnuld wrote:

1. C gives you a strong base of Procedural style of programming which
forms the basis of learning other paradigms e.g OOP

<snip>

2. with C one will learn about pointers and algorithms.

pointers: yes
algorithms: why ?

why not ?

1. i tried some Common Lisp where i never had to worry about
algorithms.

2. in C++, you get read-made algorithms from Standard Library, so
around 95% of the times, you only need to do "#include<algorithm>".

whereas in C, you have design the algorithms, from scratch.

Not necessarily. There're various utility libraries like GLib that do
most of what you might want. Even if you're forced to reimplement
algorithms in C, it doesn't necessarily follow that C's the best
language or that you've fully understood the algorithm itself.

Fact is that algorithms are independant from specific languages.
There's nothing stopping you from writing your own lists or trees even
in languages that provide them out-of-the-box.

<snip>

It might be better to take this discussion to comp.programming, as
it's having increasingly little to do with C.

[santosh]

arnuld wrote:

Have you asked permission from "arnuld" to publicise his private
correspondences?

why he needs a permission from a person like me. check my BLOG on why
i said so.

Well, usually one doesn't publish private emails on a public media
without the consent of the author of the concerned material. Never
mind.

<snip>

[arnuld]

why he needs a permission from a person like me. check my BLOG on why

i said so.

Well, usually one doesn't publish private emails on a public media
without the consent of the author of the concerned material.

yes, you are right. actually i forgot to mention that OP had read one
article on my BLOG :-)

Never mind.

:-)

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

[pandit]

from now on, this post will be discussed at "comp.programming", as it
has gone highly OT

thanks

- pandit

[August Karlstrom]

Marc Boyer skrev:

In a very few words, Ada is a modern Pascal. And Ada 83
is, to me, a very good langage to learn procedural programming.

To large. Oberon is the king in this respect.
August

[Flash Gordon]

arnuld wrote, On 22/02/07 16:29:

Please do not snip the attribution lines, the bits that say who posted
what. They are useful to the rest of us to follow the conversation.

<snip>

>>2. with C one will learn about pointers and algorithms.

pointers: yes
algorithms: why ?

why not ?

Because whatever programming language you are using you are using
algorithms, so why C in particular?

1. i tried some Common Lisp where i never had to worry about
algorithms.

In that case you were not developing your software properly. Stages of
software development:

1) What is the problem?
This is requirements analysis
2) What method do I use to solve the problem?
This is algorithm development
3) How should I put things together to implement this method?
This is design
4) Write the code

Note that I have missed out a lot of things deliberately, since software
development plans, test plans, testing and so on would complicate my point.

2. in C++, you get read-made algorithms from Standard Library, so
around 95% of the times, you only need to do "#include<algorithm>".

Where is the ready made algorithm to do histogram equalisation of a
greyscale image? How about the ready made algorithm to calculate the
gain and offset I need to apply to the incoming image so that 5% of
pixels are white, 5% black, and the rest somewhere in between? If you
can find those, then I can find other algorithms I have needed which are
*not* part of which ever language you choose to select.

whereas in C, you have design the algorithms, from scratch.

but may be i am biased, as i did not take the case of other languages
like OCaml, Haskell, Mercury or Eiffel here.

If anything you are biased by only doing programs where the language
provides you with a ready made solution. Write any program of any
significant complexity (say 100 lines, to pick a figure out of thin air)
and you will have done at least some algorithm development whether you
realised it at the time or not.

>>" i think algorithms and data-structures are more important than
learning a new programming language.

>>[SNIP]

>>/arnuld/ is not an experienced programmer, so i feel difficulty in
believing his words. i want to know the views of people here,a s much
of the post belong to C.

>On algorithms: it depends what mean 'learning about algorithms'.

i meant, "applying the specific algorithm, in the language your are
working with".

What is most important depends on what level you are working at. If you
are implementing a design that has been produced and reviewed by others
then there is sod all algorithm development to do whatever language you
are working in. If, on the other hand, you are trying to be the
technical lead on a project then if you do not understand the algorithms
that need to be developed you are worse than useless, but not knowing
all the details of a given programming language is less important
because you will find it easy to pick up what you need (prefferably be
reading good material on the language).

<snip>

>Moreover, I am under the
impression that the 'good' software design is not langage-independant.

good software design is language-independent,as i said already, *and*
some programming languages are a not a good-fit for a particular
design but a perfect-fit for some other designs.

Here I more or less agree with you. However, if you know you are going
to implement something in C or Pascal (possibly due to some external
project restraint, maybe having to add it to part of an existing
product) then you might choose a different design to if you are going to
be implementing it in Lisp.

> At leats, learning C is usefull because the is C, a kind of universal
programming langage known by all, a little bit like 'English' in
natural langages.

Is this the only benefit you think of C (except pointers) ?

i guess, there are more.

C is a higher level than assembler (which is a higher level than machine
code) which is an advantage, but one shared by many other languages.

C allows you to get close to the metal when required which is an
advantage, but one shared by many other programming languages.

C has been standardised which is an advantage shared (in one form or
another) by many other languages.

Any advantage you can find for C will be shared by at least one other
language apart from C having been ported to probably more targets than
any other language, which leads from it often being the first language
(or first after the assembler for that specific target) ported to any
given target. Assembler does not count because each assembler language
is different.

BTW, thanks for the critique.

The two things this group is best IMHO at in order are
1) C
2) Critiques.
--
Flash Gordon

[Default User]

Marc Boyer wrote:

Le 22-02-2007, arnuld <ge*********@gmail.coma écrit*:

1. C gives you a strong base of Procedural style of programming

which forms the basis of learning other paradigms e.g OOP

I am not sure that C gives better 'strong base' than Ada.

OK, 1st have to Google for Ada as i never came across some
Ada-code. i never even read about its design-goals and/or any
articles related to it.

comp.lang.ada

BTW, your "summary of Ada" can be useful for me, if you can.

In a very few words, Ada is a modern Pascal.

That's way too few. Ada was a language created from scratch for
high-safety programming, commissioned by the US Department of Defense.
It's based on Pascal, but no more a "modern Pascal" than C++ is a
"modern C".

And Ada 83
is, to me, a very good langage to learn procedural programming.

It used to be difficult to find free Ada compilers (or even any that
didn't cost a fortune). A brief bit of searching seems to indicate that
that's not so much the case anymore.

Brian

[Marc Boyer]

Le 23-02-2007, Default User <de***********@yahoo.coma écrit*:

Marc Boyer wrote:

>Le 22-02-2007, arnuld <ge*********@gmail.coma écrit*:

1. C gives you a strong base of Procedural style of programming

which forms the basis of learning other paradigms e.g OOP

>
I am not sure that C gives better 'strong base' than Ada.

OK, 1st have to Google for Ada as i never came across some
Ada-code. i never even read about its design-goals and/or any
articles related to it.

comp.lang.ada

BTW, your "summary of Ada" can be useful for me, if you can.

In a very few words, Ada is a modern Pascal.

That's way too few.

If you have time to give a long definition of Ada, just do it.

Ada was a language created from scratch for
high-safety programming, commissioned by the US Department of Defense.
It's based on Pascal, but no more a "modern Pascal" than C++ is a
"modern C".

I agree.

>And Ada 83
is, to me, a very good langage to learn procedural programming.

It used to be difficult to find free Ada compilers (or even any that
didn't cost a fortune). A brief bit of searching seems to indicate that
that's not so much the case anymore.

What about GNAT ?

Marc Boyer

[arnuld]

On Feb 23, 12:05 am, Flash Gordon <[e-mail]:

Please do not snip the attribution lines, the bits that say who posted
what. They are useful to the rest of us to follow the conversation.

ok

Because whatever programming language you are using you are using
algorithms, so why C in particular?

i guess, because it will help me in understanding all other languages
as C is the *hardest* language i have ever confronted. Assembly was
not that hard, Assembly is just *tedious*.

In that case you were not developing your software properly. Stages of
software development:

1) What is the problem?
This is requirements analysis
2) What method do I use to solve the problem?
This is algorithm development
3) How should I put things together to implement this method?
This is design
4) Write the code

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

Note that I have missed out a lot of things deliberately, since software
development plans, test plans, testing and so on would complicate my point.

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

2. in C++, you get read-made algorithms from Standard Library, so

Where is the ready made algorithm to do histogram equalisation of a
greyscale image? How about the ready made algorithm to calculate the
gain and offset I need to apply to the incoming image so that 5% of
pixels are white, 5% black, and the rest somewhere in between? If you
can find those, then I can find other algorithms I have needed which are
*not* part of which ever language you choose to select.

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

If anything you are biased by only doing programs where the language
provides you with a ready made solution. Write any program of any
significant complexity (say 100 lines, to pick a figure out of thin air)
and you will have done at least some algorithm development whether you
realised it at the time or not.

i never realised that. i always thought:

algorithms == maths != programming

What is most important depends on what level you are working at. If you
are implementing a design that has been produced and reviewed by others
then there is sod all algorithm development to do whatever language you
are working in. If, on the other hand, you are trying to be the
technical lead on a project then if you do not understand the algorithms
that need to be developed you are worse than useless,

i am not on a "team-lead". 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)

but not knowing
all the details of a given programming language is less important
because you will find it easy to pick up what you need (prefferably be
reading good material on the language).

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

C is a higher level than assembler (which is a higher level than machine
code) which is an advantage, but one shared by many other languages.

C allows you to get close to the metal when required which is an
advantage, but one shared by many other programming languages.

C has been standardised which is an advantage shared (in one form or
another) by many other languages.

Any advantage you can find for C will be shared by at least one other
language apart from C having been ported to probably more targets than
any other language, which leads from it often being the first language
(or first after the assembler for that specific target) ported to any
given target. Assembler does not count because each assembler language
is different.

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.

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.

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

The two things this group is best IMHO at in order are
1) C
2) Critiques.

:-)

Flash Gordon

i am arnuld, nice to meet you ;-)

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

[santosh]

arnuld wrote:

On Feb 23, 12:05 am, Flash Gordon <[e-mail]:

<snip>

Because whatever programming language you are using you are using
algorithms, so why C in particular?

i guess, because it will help me in understanding all other languages

It won't, atleast not as much as might think it would.

as C is the *hardest* language i have ever confronted. Assembly was
not that hard, Assembly is just *tedious*.

Trust me, C++ is a lot harder.

In that case you were not developing your software properly. Stages of
software development:

1) What is the problem?
This is requirements analysis
2) What method do I use to solve the problem?
This is algorithm development
3) How should I put things together to implement this method?
This is design
4) Write the code

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

Not really. Programming is the actual coding part. Software
Engineering is about trying to perfect the body of code, so that
behaves as well as possible within itself and with external systems
and meets the requirements defined before hand. It, (principles of
software engineering), is not necessary for trivial programs, but
it'll be really useful as projects get bigger and expectations taller.

C++, you get read-made algorithms from Standard Library, so [ ... ]

Where is the ready made algorithm to do histogram equalisation of a
greyscale image? How about the ready made algorithm to calculate the
gain and offset I need to apply to the incoming image so that 5% of
pixels are white, 5% black, and the rest somewhere in between? If you
can find those, then I can find other algorithms I have needed which are
*not* part of which ever language you choose to select.

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

No. He's saying that no language contains premade implementations of
all the algorithms you might need. The C++ library, (and many other
"Standard" libraries), contain many fundamental algorithms, but in
practical projects you'll still have to write numerous case specific
ones.

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.

<snip>

i am not on a "team-lead". 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)

Practise makes perfect. A lot of reading also helps. A clear mind is
the best help of all.

<snip attributes of C>

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. Devote a reasonable amount of time to a language before picking
up another one. Learning several languages in parallel is possible,
but difficult.

<snip>

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

Is *that* your biggest problem? I envy you. :)

[Daniel Rudy]

At about the time of 2/22/2007 3:34 AM, pandit stated the following:

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

Any language that allows subroutines is procedural based. This includes
C, Pascal, and Assembler.

2. with C one will learn about pointers and algorithms.

Pointers, yes. But, you can learn about algorithms and data structures
in any language.

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 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"

FWIW, I learned C out of a book, along with the helpful guidance of the
people here.

Algorithms are just a set of steps or tasks that must be performed to do
something. The steps used to perform a quicksort or a binary search are
the same no matter what language you use. The implementation of those
steps are going to be language dependent. Some algorithms are more
complicated than others. Quicksort, binary trees, binary search, and
hash tables are some of the more complicated ones. The most complicated
algorithms that I have ever done dealt with encryption. Ever look at
the source code for a DES algorithm? It's bad...to the point of
pre-processor abuse.

And there are the implementations of algorithms that are not just
language specific, but also platform specific. Performing network IO on
a windows machine is different than doing it on a unix machine. Even
though you are using the same language for both, the platform dictates
the procedure you must follow to do it.

Data structures are also language dependent. Pascal has record, object,
and array, C has struct, union, and array. C++ has what C has plus
class. Some languages like VBScript doesn't even have structures. But,
the basic definition of a data structure in any language is a collection
of related data. The data structure is dependent on what the format of
the data is in, and what you want to do with that data. But there are
some general guidelines.

>
/arnuld/ is not an experienced programmer, so i feel difficulty in
believing his words. i want to know the views of people here,a s much
of the post belong to C.
- pandit

I have to agree with your friend. He does seem to know what he is
talking about, but I would put the emphasis on algorithms before data
structures though. The data structures that you use are going to be
defined by the algorithm and language that you use, in addition to what
data types are available for the language that you are using.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Chris Dollin]

Daniel Rudy wrote:

Any language that allows subroutines is procedural based. This includes
C, Pascal, and Assembler.

That depends on what you mean by a "subroutine", unless you
count the pure functional languages (including the lazy ones)
as "procedural", which I generally wouldn't.

--
Chris "electric hedgehog" Dollin
"How am I to understand if you won't teach me?" - Trippa, /Falling/

[Daniel Rudy]

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

Daniel Rudy wrote:

>Any language that allows subroutines is procedural based. This includes
C, Pascal, and Assembler.

That depends on what you mean by a "subroutine", unless you
count the pure functional languages (including the lazy ones)
as "procedural", which I generally wouldn't.

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).
--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Charlton Wilbur]

>>>>"DR" == Daniel Rudy <sp******@spamthis.netwrites:

DRI think of a procedural based language as being a language
DRthat allows you to call a named subroutine (function,
DRprocedure, etc) like C, Pascal, etc.

Then Lisp is as well, as is C++, as is Java, as is PostScript, as is
TeX. I suspect your definition of "procedural based language"
requires considerable further refinement.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Flash Gordon]

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

>On Feb 23, 12:05 am, Flash Gordon <[e-mail]:

>Please do not snip the attribution lines, the bits that say who posted
what. They are useful to the rest of us to follow the conversation.

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.

>Because whatever programming language you are using you are using
algorithms, so why C in particular?

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!

>In that case you were not developing your software properly. Stages of
software development:

1) What is the problem?
This is requirements analysis
2) What method do I use to solve the problem?
This is algorithm development
3) How should I put things together to implement this method?
This is design
4) Write the code

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!")?

>Note that I have missed out a lot of things deliberately, since software
development plans, test plans, testing and so on would complicate my point.

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 ;-)

>>2. in C++, you get read-made algorithms from Standard Library, so

Where is the ready made algorithm to do histogram equalisation of a
greyscale image? How about the ready made algorithm to calculate the
gain and offset I need to apply to the incoming image so that 5% of
pixels are white, 5% black, and the rest somewhere in between? If you
can find those, then I can find other algorithms I have needed which are
*not* part of which ever language you choose to select.

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.

>If anything you are biased by only doing programs where the language
provides you with a ready made solution. Write any program of any
significant complexity (say 100 lines, to pick a figure out of thin air)
and you will have done at least some algorithm development whether you
realised it at the time or not.

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?

>What is most important depends on what level you are working at. If you
are implementing a design that has been produced and reviewed by others
then there is sod all algorithm development to do whatever language you
are working in. If, on the other hand, you are trying to be the
technical lead on a project then if you do not understand the algorithms
that need to be developed you are worse than useless,

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.

>but not knowing
all the details of a given programming language is less important
because you will find it easy to pick up what you need (prefferably be
reading good material on the 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.

>C is a higher level than assembler (which is a higher level than machine
code) which is an advantage, but one shared by many other languages.

C allows you to get close to the metal when required which is an
advantage, but one shared by many other programming languages.

C has been standardised which is an advantage shared (in one form or
another) by many other languages.

Any advantage you can find for C will be shared by at least one other
language apart from C having been ported to probably more targets than
any other language, which leads from it often being the first language
(or first after the assembler for that specific target) ported to any
given target. Assembler does not count because each assembler language
is different.

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

>Flash Gordon

i am arnuld, nice to meet you ;-)

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

[CBFalconer]

Daniel Rudy wrote:

>

.... 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[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" == user923005 <dc*****@connx.comwrites:

dcAs to why learn C... Because it is interesting and useful.
dcIt is no different than "Why learn French?" Or "Why learn
dccalculus."

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.

dcIf it is interesting to *you* to learn it then do it. If you
dcwould rather learn something else, then learn something else
dcinstead.

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

--
Charlton Wilbur
cw*****@chromatico.net

[arnuld]

On Feb 24, 12:59 am, Flash Gordon <[e-mail]:

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!

In that case you were not developing your software properly. Stages of
software development:

1) What is the problem?
This is requirements analysis
2) What method do I use to solve the problem?
This is algorithm development
3) How should I put things together to implement this method?
This is design
4) Write the code

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!")?

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.

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 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]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote

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:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote

>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.

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

[Flash Gordon]

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

>On Feb 24, 12:59 am, Flash Gordon <[e-mail]:

<snip>

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.

>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

;-)

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

>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.

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

>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.

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.

>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 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]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

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

>>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote

>>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.

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:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

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

>>>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote
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.

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.

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.
--
Flash Gordon

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

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

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]

Daniel Rudy wrote:

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

>Daniel Rudy wrote:

>>Any language that allows subroutines is procedural based. This includes
C, Pascal, and Assembler.

That depends on what you mean by a "subroutine", unless you
count the pure functional languages (including the lazy ones)
as "procedural", which I generally wouldn't.

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 "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

[Chris Barts]

CBFalconer <cb********@yahoo.comwrote on Friday 23 February 2007 13:18 in
comp.lang.c <45***************@yahoo.com>:

Daniel Rudy wrote:

>>

... 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.

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.

--
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.

[Marc Boyer]

Le 23-02-2007, santosh <sa*********@gmail.coma écrit*:

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]

"Chris Dollin" <ch**********@hp.comwrote in message

>
(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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm