Re: Book on Assembly

<randyhyde@xxxxxxxxxxxxx> wrote:
And the spaghetti students write, without having been taught
how to create reasonable control structures in assembly
language, is among the worst.

:-P If we're comparing code to spaghetti, we follow the inference
that all code exists as some form of spaghetti. And I stand behind
the statement that some spaghetti is better than other spaghetti.
That's just the way it is, whether /you/ call some code spaghetti
and refuse to call other code spaghetti, or not.

That is correct. On one extreme you have an experienced
programmer who makes an informed decision to destructure
a part of their program in order to achieve some goal...

There's a lot you're overlooking. Forget about the extremes.
You can have an inexperienced programmer who makes an
judgemental guess and or an informed decision as well. The
proposition involved giving the students a first assignment
without any training in anything. There's a reason behind it,
and it involves getting to the know each and every student.
I overlooked the fact that some instructors don't have this
capacity and they work according to their capacities, not
that this means you're incapable, I leaned into the fact that
the people taking the class:

(1) want to take the class and want to learn something, I
purposely overlooked the fact it might be a required class
for some degree, and I guess I did this for a reason. I
found personal rewards in not being afraid of any class,
and I discovered that there are two different types of
instructors for any class.

(1a) Teachers that get to know each and every student
and help those that need help.

(1b) Teachers that follow a set curriculum that and a given
set of rules with disregard to knowing the students.

(2) The instructor properly gets to know each and every
student, gets to know what the student initially knows and
gets an idea where the student might need some help.

With these two inferences, things tend to work out a whole
lot better for everyone. So forget about the imperfect world,
and pretend that you're working in an ideal world. And the
reason we employ these inferences, because the topic of
this thread deals with a Book on Assembly. We don't have
to worry so much about about getting to know the people
as much as a classroom instructor does, but in this case we
infer that Julienne Walker is willing to work with anyone, to
listen to all and to that her work provides something useful.

Now, to reiterate...

(1) All code exists as spaghetti.
(2) Some code ends up as better spaghetti.
(3) The instructor gets to know the people making the
spaghetti and provides some help when required.
(4) Infer that sometimes a fresh mind produces a better
spaghetti. This means that their spaghetti possibly tastes
better than your spaghetti. I think the spaghetti analogy
works well in regards to taste. Sometimes readability
tastes better, sometimes size tastes better and sometimes
speed tastes better. I initially stated an argument that
spaghetti represented a poor analogy. The reason that
I leaned in that direction involves: (1) spaghetti, and (2)
NOT spaghetti. Only two sets exists. The second set
only exists from the student that fails to turn something
in. So, as long as ALL code equates to some type of
spaghetti...

It's an ideal world. We don't have to worry about too many
complaints here. And if anyone complains, Julienne only
needs to receive it as constructive criticism. There's more to
this conversation than just a classroom with some indigents.

And one way instructors point this out is by showing how
to create all the classical control structures in assembly
language.

Perfect. But you still need to get to know the students, where
they come from, where they're going, how to help each.

You infer that you represent the God of the class. However,
even God must listen. And you are definitely NOT the know
it all type of God. Keep your mind open to that fact. You
come across as an intelligent person that can add value to
everyone. Keep it that way. <g>

<snip>...</snip>

40 years of software engineering has taught us a couple of
things. Among them, spaghetti coding is bad. Yes, there are
a *few* exceptions to the rule.

If you call one set of code spaghetti, all code must be spaghetti
and spaghetti represents code. The only thing that represents
NOT spaghetti is no code at all (the empty set). After all,
whether you break wind out of a loop or pass gas to another
address, it, like ..it or not, ..it happens.

It appears pointless to not reference assembly language as
spaghetti. Even in the higher level languages, even with the
simplest program, the code ends up as spaghetti. You simply
can not call some code spaghetti and call other code some-
thing else, what ideal? It's definitely ALL spaghetti.

How is that? More often than not, such code (the first
project based upon students coding with no knowledge) is
incomprehensible.

The point I drove home involves an initial project to get to
know what the students are capable of. I based it upon the
fact Evenbit suggested NOT providing information on how
to create macros (for an initial book on assembly language).
He suggested teaching readers how to employ branching,
rather than macros. You replied from /your/ classroom
point of view. It seemed a bit critical and narrow-minded
when I read it. /You/ inferred that ALL the code received
from students in a classroom came to you as spaghetti. I
replied, going along with that idea, and suggested that
ALL code really is spaghetti.

I'm not going to argue with your statement that some code
is "incomprehensible". That's pointless to argue. <g>

I stated...
I'll argue with you Randy, not against the structured
approach, and not against teaching the fundamentals,
but against the nonsense about spaghetti. I believe it's
a rather poor analogy and presents spaghetti in a
negative demeanor, and I'll attempt to present the
same spaghetti in a positive light.

Once you have your so called spaghetti from each (and
hopefully every student,...

You conjured up...
And, at the end of all of these, you wind up with a bunch
of students bitching about how bad the instructor is for
not teaching them how to do the task at hand. And such
bitching is highly justified in that case.

The discussion involves Julienne writing a book on assembly
language. Evenbit provided a suggestion. You came in from
your /classroom point of view/ and interpreted from /your/
classroom mentality.

I'm not here to criticize you, Randy, and I hope this comes
across as a little constructive criticism. Keep your mind open
to others' suggestions. :-) The world isn't /your/ classroom,
it's a world of learning, even for those that know everything,
for God can't possibly know everything if she doesn't listen to
everyone. The world is a place for all to work together and
help each out, even with those flatulent ones that stink things
up. You just have to ignore the stink (or scoot to another
area if possible).

I'll point out some items which hint at how your classroom
approach might hinder your line of thoughts.

You stated:
Teaching is about reaching the *average* student.

Even in a classroom, this completely falls apart.

(1) There is no such thing as an average student. The only
time an average student exists is when some administrator
creates an "average student" and expects someone to fall
below average and others to go above average. There is
no such thing, it's just a statistic.
(2) Each student is an individual and has specific needs.
(3) You hinder no one by helping those that need the help.
That's what books are for. The books provide the material
to read and learn from when the instructor goes off to help
some individual.

Sometimes I wonder about the things that go on inside classes.
I wonder if everyone passes with an 'A' grade, does the college
condemn the instructor for NOT failing someone? Does the
college dodaddies EXPECT a certain statistic? This is way off
topic, because was about Julienne's book. And now it's about
/Randall Hyde's/ classroom. I hope Julienne and Randy do not
mind.

IF I were to guess about /your/ classrooms, Randy, I think
/your/ classrooms involved 50 or more students at a time. I'll
let you define the average number of students in /your/ class-
room. I'm curious.

That's about all I've got to say. <g> Look forward to replies.

--
Jim Carlock
Post replies to the group.


.

Relevant Pages

  • Re: Book for VB .NET newbie/novice
    ... runtime that actually processes the code written in a given .NET language. ... My take on what Cor is saying is that you don't need to worry about what ... > showing that if you don't want to write spaghetti programming, ... > to overcome the spaghetti programming, so the CLR isn't as necessary. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Delphi or PHP ?
    ... language that doesn't produce spaghetti. ... Smarty source code, I'm not so impressed with the philosophy behind php ... It is not a fault of the language, but rather people who are using it. ...
    (borland.public.delphi.non-technical)
  • Re: Reading text file with CStdioFile.ReadString
    ... I knwo enough to ... a nice bowl of spaghetti. ... It hardly matters what the language used is. ...
    (microsoft.public.vc.mfc)
  • Re: E. W. Dijkstra VS. John McCarthy. A rebuttal to Paul Grahams web writings.
    ... Anyone here care to admit using it? ... At the university [department of computer science] we called Basic a ... "spaghetti" language. ...
    (comp.lang.lisp)