Newbie

[luser-ex-troll]

Having a modern printing of K&R is most useful, and the comp.lang.c
FAQ covers many gotchas in the language. When you are familiar enough
with K&R, then you're probably well-enough equipped to start referring
to the C standard(s) - for the closest approaches to those, grab
"n869.pdf" and "n1256.pdf".


You're doing better than several of the regulars!


1982, aged 11, BASIC on some mini the size of a large wardrobe
with no real security at all. I still remember my first day at
the console, after waiting 5 minutes at the start of the lesson
for the bugger to boot up, and the 'hello' prompt I was offered.
I forget what response my 'hello' elicited, but I clearly
remember the response to my next command - 'bye'. 10 minutes
later, after the machine had been rebooted, the 24 of us began
our class again... (I have no idea what the machine was - if
anyone has any vague clue what it might have been, please fling
random suggestions in my direction. I seem to remember the
command to log in was something like "login 8,8", where 8 was
my terminal number.)

I didn't meet C until ~1987, but a multi-floppy-disc compiler
on a single-floppy Atari ST was no fun at all, and I didn't
do anything with it. However, when I got access to a PC with
TurboC on it, my programming life changed dramatically!

Wow! I'm kinda surprised that BASIC keeps showing up on lists of first
languages. I got my first computer around 1988 at age 10, a 286; and
around the same time there was a programming elective in school that
taught BASIC on Apple IIE's. The school lab also had a Mac Plus and a
386. I moved to Pascal and burned out. I rediscovered programming (and
C) in 1996. It seems mid-teens learning basic in school is right on
track. You might be able to talk your teacher into giving you extra
credit for submitting C answers in addition to VB. Maybe not, but
asking may lead to other useful conversations.

 

[Guest]

There are many C programmers here with a wealth of real world C
knowledge who would be more than happy to help you-. Whether it be to
choose an IDE, Editor or Compiler. Feel free to ask away. There are
some, like Chuck, who are not really experienced world programmers and
their sole contribution to the C world are some college level libraries
they are inordinately proud of - I would advise ignoring such people.

beware. Richard <without surname> is a semi-troll. He does post useful
technical information but he also has "a bee in his bonnet" about
certain posters whom he dislikes. Chuck (who also posts useful
technical
information) is on Richard's list. No doubt this post will attract a
counter blast. All I can suggest is you use google to review poster's
past
posts and make your own mind up.

<snip>

 

[Guest]

If you're happy with that combination then go for it.

My advice is to use a good editor like that but to also integrate the
usage of a good debugger such as gdb into your development cycle.

sigh. This is *another* one of Richard's bees in bonnets.
Again review past posts.

My view is that a debugger is useful for finding bugs. Particularly
after a crash. Richard seems to advocates "stepping through" working
code. I'm not sure why.

There are other ways to produce error free code such as test
harnesses.
Use of diagnostic logs. Judicious use of assert(). And careful
reasoning
about programs.

Many
people here claim debuggers are for bad programmers - ignore them.

The claim is that over-reliance on debuggers is bad practice.

They are often idiots and trolls showing off.

Not everyone (or even everyone who is technically competant) agrees
with this.

You will need debuggers later
in your career to help you follow other peoples systems

I disagree.

and to set break
and conditions to manipulate the program.

I've never seen the point in this. (I assume by "manipulate" you mean
change program variable values on the fly).

get used to using one now. Agin some people will claim they never used one.
who?


I never worked
with a good developer who didnt use debuggers a lot. Frankly I dont
believe some of the posters here. But all NGs have the "elite" who like
to conjure up an aura of god like skillsets. With that in mind you might
consider using Eclipse or code::blocks. Or maybe even visual studio if
you're on an MS platform. gdb is not trivial but you will learn a LOT
from it. And its written by Richard Stallman - and he thinks debuggers
are necessary...

Oh, if we're going to cite authority lets try:-

"I don't like debuggers. Never have, probably never will. I use gdb
all the
time, but I tend to use it not as a debugger, but as a disassembler on
steroids that you can program."
Linus Torvalds

I recommend you read this and make up your own mind:

http://dirac.org/linux/gdb/01-Introduction.php#whatisadebugger

Pay particular attention to "Why not use printf()".

Using printf is kludgy, error prone, slow, inefficient and itself a
source of bugs in many, many cases.

But as I say, keep an open mind, read the document and see what YOU
think.

Quite...

Richard is probably quite genuine about his opinion though he seems to
impute bad motives to people who disagree with him. Just be aware
that Richard's "debugger heavy" approach is not the only way.

 

[James Dow Allen]

IIRC, we called the 1620 a "CADET" machine.  "Can't Add, Doesn't Even
Try".

It had an addition table in low-core. To avoid pranksters
overwriting the table to give 2+2 = 5, the table was reloaded
at the beginning of every program. The routine that loaded
the table couldn't use addition, but once the table was loaded
the 1620 did "Try to Add"!

Although I used the 1620 at San Jose State in 1966, the
very first computer I used was a Sys 360/20. IIRC, when
using the 7-pass Fortran compiler, one passed the
source-code deck through the card reader seven times.

James Dow Allen

 

[Ben Bacarisse]

[In an attempt to keep this in the right place I have added
comp.programming and set followups to there. I think that is the
right place for this part of the discussion.]

On 24 Mar, 00:05, Richard <[email protected]> wrote:

The claim is that over-reliance on debuggers is bad practice.

Well that is almost a tautology -- over-reliance on anything is bad,
by definition!

This has been a contentious subject here and I think a beginner
deserves to have both cases outlined in a reasonably neutral way, so I
thought I'd have a go...

Amongst a whole range of views about programs there are two that often
clash. One sees a program as a machine that calculates -- with
interlocking gears and linkages that spin and oscillate, moving data
along, producing output. The other sees a program as a mathematical
object or a text whose meaning is to have some effect on its
environment (for imperative languages like C) or to yield a value (for
declarative languages).

The first is an engineering view that stresses the dynamics of program
execution and the second is a mathematical one that stresses the
static analysis of the program text. Neither is absolute: the
engineering view values the static mathematical approach, and the
mathematical view can include the dynamics of the execution, but they
characterise two extremes on a spectrum of views.

Both views have attendant corollaries. For example, the idea that a
program has a bug belongs to the first. In the view of an extreme
formalist, no program "has a bug" -- a program either correct or it is
not (or more likely it is still correct it is simply another program,
rather than the one you intended to write). People who favour heavy
use of a debugger usually lean towards the first view, whereas those
who are sceptical of a debugger's value as a tool for understanding a
program lean towards the latter.

For example, I have never found it useful to watch a program execute
as a way of understanding it. There is, for me, too much data and not
enough meaning. I prefer to study the text. I do not do *only* that,
just as people like Richard <no name> almost certainly does not ignore
the text when using a debugger, but we each prefer a different primary
source. Richard might be tempted to claim that I don't know how to
use a debugger properly and I might be tempted to say that he does not
know how to reason about programs, but we would both be wrong to do
that. I suspect a complex mix of personality, prior experience and
the way we were taught all mean that neither of us is able to much
about it now.

To complicate matters, there is another view that programming is a
craft (or an art). This view comes from the observation that good
engineering is based on science (and there is very little science
underlying software engineering) coupled with the feeling that a
rigorous mathematical approach is not yet practical (and may never
be). If you drew a picture of a triangle like this:

craft
/ \
/ \
/ \
/ \
/ X \
/ \
/ \
engineering ----------------- mathematics

most people could put themselves somewhere on it (I have marked
myself with an X) though more resolution would enable people to draw
fuzzy regions.

Let me illustrate one educated view form one edge of the triangle with
a quote:

"The required techniques of effective reasoning are pretty formal,
but as long as programming is done by people that don't master them,
the software crisis will remain with us and will be considered an
incurable disease. And you know what incurable diseases do: they
invite the quacks and charlatans in, who in this case take the form
of Software Engineering gurus."

Edsger W. Dijkstra
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1305.html

 

[Default User]

Don't rule out a library. My local library is just rubbish for
anything up-to-date and technical, but even they have a copy of K&R2
(which seems never to be out on loan). The fact that it is (a) old
and (b) a classic helps in the case.

Most libraries can get books via inter-library loan as well.




Brian

 

[Echo Weep]

On Mon, 23 Mar 2009 04:15:00 +0000, Echo Weep wrote:

Well given the fact that this my first usenet posting experience (thread
if you will) I certainly wouldnt want it to turn into my first usenet
flamewar experience. So for the sake of "usenet peace"(and productivity),
before the conversation becomes any more hostile, I declare this thread
closed! (Unfortunately I cant physically close a thread given the nature
of usenet) But I can say that my "issues" have been resolved. Once more I
thank everyone that has taken the trouble to help me and appreciate your
efforts. Hopefully my next posting will be on a more interesting
(technical) issue.

Regards

Echo

 

[CBFalconer]

.... snip ...


beware. Richard <without surname> is a semi-troll. He does post
useful technical information but he also has "a bee in his bonnet"
about certain posters whom he dislikes. Chuck (who also posts
useful technical information) is on Richard's list. No doubt this
post will attract a counter blast. All I can suggest is you use
google to review poster's past posts and make your own mind up.

Richard the nameless hasn't posted any troll-type info in this
thread (at least as seen in quotes, since I have him plonked), so I
haven't commented.

 

[CBFalconer]

CBFalconer said:



Perhaps you missed the article by Nick Keighley:

<[email protected]>

in which he quotes Richard sans Surname as making the following,
patently false, statement:

"Many people here claim debuggers are for bad programmers - ignore
them."

Well, I think that is pretty mild, and basically an opinion. So I
paid it no attention whatsoever.

 

[Barry Schwarz]

IIRC, we called the 1620 a "CADET" machine. "Can't Add, Doesn't Even
Try".

That was true of the model 1. The model 2 had addition circuitry but
still used a table look up for multiplication.

 

[luser-ex-troll]

(e-mail address removed) said:


Right. There are lots of ways to find bugs, and *thinking* is the
most important of those ways.

I'd just like to point out that even if you don't use a debugger while
designing and implementing your code, there is still the sheer delight
of watching the values in the variables dance to your choreography.

Learning to use a debugger can provide useful insight into the
language and the behavior of the computer under the guidance of your
program.

 

[Keith Thompson]

Posting incorrect information is one of the characteristics of a
troll, but only in certain contexts. A comment like the above
hardly qualifies. And, it is in fact correct. I have many times
seen people make the bogus claim that debuggers are for bad
programmers. ( Although it is entirely possible that only one
person has made the claim multiple times, and that the claims have
blurred in my memory to become claims from many people, but the meat
of Richard's claim is perfectly valid.) This is not to say that
Richard has not on many occasions behaved in a troll-like fashion,
but I would agree with CBF that in this thread he has not. (Unless
he himself has claimed that debuggers are for bad programmers, in
which case the statement cited above would qualify.)

Really? I don't recall anyone making that specific claim here, that
"debuggers are for bad programmers". Can you provode a citation?

 

[Guest]

I'd just like to point out that even if you don't use a debugger while
designing and implementing your code, there is still the sheer delight
of watching the values in the variables dance to your choreography.

I've never found had this delight

 

[Bartc]

On Mar 23, 5:35 pm, Phil Carmody <[email protected]>
wrote:

Wow! I'm kinda surprised that BASIC keeps showing up on lists of first
languages.

Well, the B in Basic stands for Beginner's. And it's interactive nature
meant you didn't have to worry about the concepts of compiling and linking
or whatever other baggage was needed on those early machines.

And it's string handling was outstanding, better even that C's today.
(Although I've never used Basic myself, only admired it)

 

[James Kuyper]

William Pursell wrote:
....

... I have
many times seen people make the bogus claim that debuggers
are for bad programmers.

If this has indeed happened many times, it should be easy to find an
example you can cite.

 

[Kenny McCormack]

Go on, then, don't keep us all in suspenders.

What? You don't know how to use Google to search newsgroups?

I'm sure Han could help you with that. You might prefer to do it in
private email, though. I'm sure it is OT here.

 

[Chris Dollin]

But then again, you supposedly don't read my posts either, Billy.
So perhaps the best move for you here is either to find a different
example that supports your claim (I've found four other examples
in only ten minutes of searching, one from Ian Collins)

Go on, then, don't keep us all in suspenders.

 

[Chris Dollin]

What? You don't know how to use Google to search newsgroups?

Kenny, are you telling me that the Google results come with little
pink "Han found me" tags? Truly Google have some wonderful technology.
I swoon.

I'm sure Han could help you with that.

I'm sure he could. But in this case, that's not what's asked for.

 

[Chris Dollin]

This is certainly an unusual responder for the Thompson, Heathfield,
& Co. piggyback assist! Good to see I have another loyal reader, though.

Your ability to draw false conclusions does not surprise me.

I'll note you down on my growing list, dude.

I don't need growing, thankyouverymuch.

This is a poker game, Chris. As you saw when Heathfield denied
having plugged his commercial product, the idea is first to lure
them into untenable positions before playing the best hand.

Great heavens, that's a tactic hardly limited to poker.

Doing otherwise is anticlimactic. Watch how this thread plays out.

As I expected, you declined the opportunity to present the "four other
examples in only ten minutes of searching, one from Ian Collins".

BLUFF.

 

[Guest]

I take it, then, you agree with the above?

I took it to be a troll as it seemed posted mainly to irritate.
Normally I ignore the ~50% of Richard <no name>'s output that
is from this template, but he was responding to a newbie so
I thought I'd counter-respond