A new way to learn C?

M

Martin Dickopp

Martin Johansen said:

There seem to be many incorrect statements, like

"A byte consists of 8 bits [...]"
"A byte is mapped into a character by the ASCII table."
"long means a variable is of integer type, of byte length 4."
"A C comparizon compares a value to 1 [...]"

just to quote a few. I suggest that before you write C tutorials, make
sure you master the C language yourself.

Martin
 
O

osmium

Martin said:
Ok, its experimental, but what do you think about the style?

I don't like the style, it's too terse. The idea is to communicate, not to
use as few words as possible. Decide who your audience is. Is it for a 12
year old boy who likes to play some computer game? Do you think he knows
what a "character" is? What "syntax" means? Is he supposed to have a
dictionary by his side? If so, why? There is nothing wrong with having one
available, but *open* - and on the desk???

You seem to have a goal of using a bunch of things I will call axioms for
now. But axioms are used to prove something, not to learn something. A
beginner is not interested in proofs, he just wants the darn program to run.

I think you are expecting the reader to sit there and ponder over these
pithy phrases and have some kind of epiphany. He doesn't have the
background to cause such a wonderful thing to happen.

I am not a big expert on your role model, Euclid, but my guess is that he
was addressing his would-be peers, not a group of neophytes.
 
A

Arthur J. O'Dwyer

I have written this tutorial on the C programming language, named the
Elements of C.

Problems:
Your "tutorial" isn't going to engage any students, because students
generally don't like reading "tutorials" that start off with "A program
is ordered action descriptions." Too opaque. What the heck is an
"action description"? Even the C Standard won't help them determine
that, and the Standard is the repository of all that is C. ;-)
Your English doesn't seem to be up to the task: "An argument is a
program premis defined at its initiation." "A C type consists of a
length in bytes, which byte contains what, a noun, and how they are
to be treated, an adjective." I respectfully suggest you either write
in your native language (although that would tend to limit your audience,
I suppose) or get someone to proofread your stuff and make sure it is
comprehensible.
Your HTML is broken; you try to use literal <angle brackets> in plain
text, and HTML doesn't allow that. Look up &lt; and &gt;, or else
look up Content-Type: text/plain. (I think I spelled that right; it's
off-topic here anyway.)
A lot of sentences in your "tutorial" are just plain false. This
is a terribly bad thing for a tutorial. 'Nuff said.
This C tutorial is different in the way that it tries to state facts
once, then build new facts with them. The idea is to learn a fact by
learning further facts.

I hope you realized just after hitting "Send" how ridiculous that
looks in writing. How does one learn a fact by "learning further
facts," especially if the further facts depend on the former facts'
being understood? (Fortunately, not a whole lot of your "facts"
depend on each other in any meaningful way. The "noun" bit quoted
above is thankfully never referred to again, for example.)
Information is condened, so the reader is
motivated to think about the things he reads, instead of being fed
page-long explanations. Therefore, the tutorial is relatively short.


But it's wrong! Also, it fails to cover anything resembling
functions, headers, the 'main' function, the preprocessor,...

The focus is not only put on the concepts that builds the C language,
but also on those concepts dealing with programs in general. It is not
formalistic, but focuses on general and practical definitions.

s/not//g
With that in mind, here is the link to the site where you can download
the tutorial:

http://www.denotesoftware.com/?page=elements&title=Elements

-Arthur,
and btw nobody uses Word anymore ;)
 
K

kal

Martin Johansen said:

You have tried something and ought to be comended for that.

Euclid is not a game that two can play at. Take the following
statement in the aforementioned web page (to start with it is
missing some kind of article "a"/"an"/"the.")

"A program is ordered action descriptions."

First you have to unambiguously define or postulate what are
meant by the terms "program", "ordered", "action" and
"description."

Note that Euclid was verbose.
 
J

Jack Klein

Hello group

I have written this tutorial on the C programming language, named the
Elements of C.

This C tutorial is different in the way that it tries to state facts
once, then build new facts with them. The idea is to learn a fact by
learning further facts. Information is condenced, so the reader is
motivated to think about the things he reads, instead of being fed
page-long explanations. Therefore, the tutorial is relatively short.

The focus is not only put on the concepts that builds the C language,
but also on those concepts dealing with programs in general. It is not
formalistic, but focuses on general and practical definitions.

With that in mind, here is the link to the site where you can download
the tutorial:

http://www.denotesoftware.com/?page=elements&title=Elements

Thanks!

Aside from being littered with an extremely large number of errors
about the C language itself, you make what I consider to be an
extremely serious mistake.

You define your own terms rather than using the terms from the C
language standard.

This does a great disservice to anyone seriously attempting to learn
anything from the standard. They will eventually converse with
someone who has learned the language properly and will be using
completely different terminology. The end result is that they will be
dismissed as ignorant.
 
M

Martin Johansen

Hello group

I have written this tutorial on the C programming language, named the
Elements of C.

This C tutorial is different in the way that it tries to state facts
once, then build new facts with them. The idea is to learn a fact by
learning further facts. Information is condenced, so the reader is
motivated to think about the things he reads, instead of being fed
page-long explanations. Therefore, the tutorial is relatively short.

The focus is not only put on the concepts that builds the C language,
but also on those concepts dealing with programs in general. It is not
formalistic, but focuses on general and practical definitions.

With that in mind, here is the link to the site where you can download
the tutorial:

http://www.denotesoftware.com/?page=elements&title=Elements

Thanks!
 
M

Martin Johansen

Martin said:


There seem to be many incorrect statements, like

"A byte consists of 8 bits [...]"
"A byte is mapped into a character by the ASCII table."
"long means a variable is of integer type, of byte length 4."
"A C comparizon compares a value to 1 [...]"

just to quote a few. I suggest that before you write C tutorials, make
sure you master the C language yourself.

Martin

Ok, its experimental, but what do you think about the style?

- Martin
 
M

Martin Johansen

Thanks for the reply.
I don't like the style, it's too terse. The idea is to communicate, not to
use as few words as possible. Decide who your audience is. Is it for a 12
year old boy who likes to play some computer game? Do you think he knows
what a "character" is? What "syntax" means? Is he supposed to have a
dictionary by his side? If so, why? There is nothing wrong with having one
available, but *open* - and on the desk???

You are right in what you are saying. The goal was to produce a tutorial
which is terse, clear and straight to the point.

With the plan of the tutorial I wrote down a set of words which the
reader should know before reading, which I will add in an introduction.
These word will filter out or prepare the readers, I think.
You seem to have a goal of using a bunch of things I will call axioms for
now. But axioms are used to prove something, not to learn something. A
beginner is not interested in proofs, he just wants the darn program to run.

Nothing is proven in the tutorial...
I think you are expecting the reader to sit there and ponder over these
pithy phrases and have some kind of epiphany.
Exactly!

> He doesn't have the
> background to cause such a wonderful thing to happen.

I think all have the potential to, and I actually think learning is
about pondering on definitions of concepts and not being fed without
thinking..
I am not a big expert on your role model, Euclid, but my guess is that he
was addressing his would-be peers, not a group of neophytes.

Here is a quote about Euclide's The Elements:

"No other book except the Bible has been so widely translated and
circulated."

It has actually been used as a math text book for over a millenia, as a
complete matematics textbook from elementary school up. Its just the
later century or two we have gotten these books which explain everything
extensively, leaving almost nothing to the reader to ponder..
 
A

August Derleth

Thanks for the reply.



You are right in what you are saying. The goal was to produce a tutorial
which is terse, clear and straight to the point.

With the plan of the tutorial I wrote down a set of words which the
reader should know before reading, which I will add in an introduction.
These word will filter out or prepare the readers, I think.

This will scare off a lot of people. Plus, it isn't how anyone else on
Earth writes. Now, there's something to be said for trying new things, but
trying some things is bizarre for no good reason (such as holding the
tines of a fork in your hand and trying to spear food with the handle).

More importantly, humans can't be programmed this way. And, yes, your
document looks like an attempt at a program. (A flawed, often misspelled
attempt, but that's not the important thing.) Humans like text that flows
and interrelates to itself, not masses of facts shoved at them all at
once. Even geeks, who value high information content, like reading
organized prose.

As I've said, your lack of coherent organization is a huge, fundamental
flaw. It's so deep that fixing anything else would be useless until that
is remedied.

Nothing is proven in the tutorial...

Then why present it like one of Euclid's proofs?


Not gonna happen. Not with humans, anyway.

I think all have the potential to, and I actually think learning is
about pondering on definitions of concepts and not being fed without
thinking..

Being fed is one thing. Being drawn in by crafted prose and actual
organized thought is another.

How about this: Plenty of people write textbooks at an advanced level,
aimed at people who presumably know how to learn and know how to reason.
I'm talking about doctoral candidates, here, not simply run-of-the-mill
college kids. Nobody, but nobody, who writes those advanced books expects
the audience to sit through page after page of unrelated sentences. They
take the time to create paragraphs, sections, chapters, and so on, simply
to make their books usable by human beings.

They don't spoon-feed anyone. They do take the time to make something
worth reading.

Here is a quote about Euclide's The Elements:

"No other book except the Bible has been so widely translated and
circulated."

It has actually been used as a math text book for over a millenia, as a
complete matematics textbook from elementary school up. Its just the
later century or two we have gotten these books which explain everything
extensively, leaving almost nothing to the reader to ponder..

Bah. Learning from The Elements instead of a good textbook is missing the
point. The Elements is an example of formal rigor and a foundation for
future work in the field, and is intended for people who already
understand the field. A textbook is, presumably, meant to prepare the mind
and introduce basic concepts. Not as axioms, but as /ideas/. Its
organization is conducive to humans, not logical methods.

How about this: A bit less than a century ago, Russell and Whitehead
created a book called 'Principia Mathematica'. In it, they go from basic
formal logic to 1 + 1 = 2. They rigorously prove each step, and it takes
them hundreds of pages to reach a result the vast majority of humans grasp
intuitively as infants. Shouldn't we all use that book instead of
arithmetic textbooks?

If you want to see a C textbook done correctly, buy a copy of "The C
Programming Language, Second Edition" by Brian W. Kernighan and Dennis M.
Ritchie. They don't spoon-feed you, but they do present the material in a
human-readable way. Plus, you'll almost need to read it at some point,
since it's the best book about Standard C. In my not-so-humble opinion,
nobody who hasn't read that book should presume to write his own C
tutorial.
 
F

Fao, Sean

Martin said:
Hello group

I have written this tutorial on the C programming language, named the
Elements of C.

This C tutorial is different in the way that it tries to state facts
once, then build new facts with them. The idea is to learn a fact by
learning further facts. Information is condenced, so the reader is
motivated to think about the things he reads, instead of being fed
page-long explanations. Therefore, the tutorial is relatively short.

I've met nobody that could possibly learn from that tutorial. The human
mind can only take in so much information at a time. Unfortunately,
when you list fact after fact in that fasion, most of what is read will
*not* be retained. That's why _most_ authors write books the way they do.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,142
Messages
2,570,820
Members
47,367
Latest member
mahdiharooniir

Latest Threads

Top