Re: Book on Assembly


Jim Carlock wrote:
<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.

You're redefining a long-used term to fit your argument. Sorry, I
refuse to play this game. Though there isn't a *formal* term for
"spaghetti code", attempts to claim that code people recognize as
well-structured code "just another form of spaghetti" does not suit
your argument. If you must insist, then the students produce *bad*
spaghetti code and that is to be avoided.


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.

You have 10 weeks and 100 students. How much time are you going to
waste on your little social experiment? Sorry, the goal is to teach as
many students as possible the subject at hand, in the time available.
Getting all "warm and fuzzy" isn't going to work. And sad to say, but
with the class sizes in typical universities today, you can forget
about getting to know those students as individuals. You're lucky if
you get to know 5% of them on an individual basis (well enough to make
informed decisions). Do keep in mind, please, that a typical University
instructor teaches between 2 and 4 courses per quarter. Sometimes
you're lucky and the class size is 30 (or fewer students). Sometimes
you're unlucky and the course size is 400. Another thing to consider
is that at many schools, the instructor doesn't grade the assignments.
You have TAs or readers doing the chore. After all, if you've got three
courses with 100 students each in them, it's unlikely the instructor is
going to be able to handle the load of 300 assignments per week, along
with all the other tasks needed to teach those courses. In such a case,
trying to get a feeling for the individual capabilities of your
students is impractical.


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.

Again, imagine having 400 students per quarter.


(1b) Teachers that follow a set curriculum

This is not incompatible with (1a). In particular, note that some
schools *require* the instructor to teach a course using a set
curriculum. This is done so that the course is consistent from term to
term and instructor to instructor.

that and a given
set of rules with disregard to knowing the students.

This does not necessarily follow from the first half of (1b). And it's
also the case that teachers can get to know each and every student,
helping them learn, etc., etc., and still teach them *the wrong thing*.
I.e., your generalization is a bit simplistic. Again, having worked on
"both sides of the fences" in this area, I would suggest that things
are not quite as simple as you would like to believe.





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

Again, imagine having 400 students per quarter.



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.

The problem with that approach is that what you're suggesting doesn't
scale up in the real world. You *can't* get to know each and every
student individually. That's just impractical. And by attempting to do
so, you reduce the educational experience. What you're suggesting
works good when you have small class sizes -- and it's very rewarding
(as an instructor) when you get to do this. Alas, you don't get to do
it all that often.

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.

So you claim. That's not the traditional use of the term and it's
certainly not the way I'm using it. If you want to communicate clearly,
you have to use the term the same way everyone else does. And
"spaghetti code" implies that the control structures in a program
follow no logical, well-defined, structure. And this is the kind of
code that *most* students will write if left to their own devices when
learning assembly, without being taught how to do structured
programming in assembly.


(2) Some code ends up as better spaghetti.

Sure. Some of it even winds up as decent, structured, code. Not every
student is incapable of figuring out how to write structured code on
their own. But the point is to *teach* the students how to do this, not
waste their time struggling to figure it out on their own.


(3) The instructor gets to know the people making the
spaghetti and provides some help when required.

Why waste the students' time? Why not *teach* them how to do it write
in the first place?

(4) Infer that sometimes a fresh mind produces a better
spaghetti.

Nonsense. You're misusing the term at best. Learn to use the term
properly and you can communicate better. Some students write structured
code without any training, others write spaghetti (unstructured) code.
The goal is to teach them to write structured code from the very
beginning, period. You gain almost nothing by allowing students to
write unstructured code.


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.

This analogy is *way* off track. I suggest that you try grading about
50 assignments from a class taught the way you suggest before you
continue with such proclamations.


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

Whatever you say. You're so far out in left field at this point, I
don't even know why I'm responding. Again, try *teaching* a class
sometime and practice your ideas there. It is amazing how idealistic
concepts get thrown away when faced with teaching students in a
real-world environment. I know I sure when through some reevaluation
when I discovered my original concepts about how a class ought to be
taught didn't work out. The problem with brand-new instructors is that
they come in with a lot of ideas that would work for teaching *them*
and then they discover that what works for them doesn't usually work
for the typical student, and certainly not all the students. Over the
decade+ that I taught assembly language at the University level, I
completely reorganized the course at least four times in an attempt to
reach more students. And that's above and beyond the usual tweaking
that occurs every term.


It's an ideal world. We don't have to worry about too many
complaints here.

Tell that to the real-world students.

And if anyone complains, Julienne only
needs to receive it as constructive criticism.

But why start off doing something incredible bad, something that we've
known is bad since the 1970s? Structured coding is a big win. Maybe
you've not looked at enough 1960's-era FORTRAN code to understand the
problem. Certainly, you've not seen the kind of code students produce
if they have to hack out control structures on their own without being
taught how to do so. Why should Julienne (or any other author, for
that matter) ignore everything we've learned about programming, and how
to teach programming, over the past 50 years?


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.

Again, imagine you have 400 students in 10 weeks, plus you've got to
prepare lectures, assignments, lab exercises, attend department
meetings, etc. As I said, it's a wonderful idea but it doesn't scale
up. The bottom line is that a *good* instructor has about 10-15 hours
per week that can be devoted to meeting with students (usually during
office hours, when students are seeking help with problems). Over a
10-week quarter, this gives you an average of about 2.5 hours per
student. *Most* students will not take advantage of this time. Indeed,
I've had some office hour periods where *no* students showed up
(generally, they show up if an assignment is due the next day and
that's about it). As for judging students based on their assignments,
the last school I taught at alloted 1.5 hours per quarter per student
to grade *all* homework assignments. Of course, some students drop,
others don't turn in all assignments, so you might get 3-4
hours/student when it's all said and done, but during that first week
when you're trying to learn all about the student, you get the highest
submission rate. Do the math. You're not going to learn much about
individual students. You *might* get a feel for how the class is doing,
statistically, but individual students? No way.


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>

Where did I infer that? I've simply said that left to their own
devices, students write horrible "spaghetti" (as in unstructured)
control structures and they should be taught the proper way to do that
from the very beginning. The students *prefer* it this way. They don't
like struggling to figure this stuff out on their own and more than the
graders like reading the stuff. It's much better for everyone all the
way around if they're taught how to do it properly from the beginning.



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.


You are really hung up on your misinterpretation of the term "spaghetti
code." Get over it. We're talking about unstructured code here.

It appears pointless to not reference assembly language as
spaghetti.

Wrong. You can write structured code in assembly language. Structured
code is *not* about using a specific set of statements (IF, WHILE,
etc.) in a program. It is about how you organize the flow of control in
the program. You might try looking up the terms "reducible flow graph"
and "irreducible flow graph" some time. Spaghetti (unstructured) coding
produces irreducible flow graphs.


Even in the higher level languages, even with the
simplest program, the code ends up as spaghetti.

You don't know what you're talking about. Sorry to be blunt, but you're
just making stuff up to argue.

You simply
can not call some code spaghetti and call other code some-
thing else, what ideal? It's definitely ALL spaghetti.

Okay, you can't get a handle on spaghetti or structured code? Let's be
formal. Reducible flow graphs vs. irreducible flow graphs. Beginning
students left to their own devices tend to produce code that has an
irreducible flow graph. That's a *formal* definition of what they're
doing wrong and it's (producing irreducible flow graphs) something we
want to avoid.



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.

Again, imagine you have 400 students. Do the math. You're not going to
learn much about the indivduals. Sad fact of life, but reality. Deal
with it.


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.

Forgive me for thinking that everyone understood the meaning of the
term "spaghetti code". In your instance I was quite mistaken. Of
course, if I had been a bit more precise and said that the students
produced irreducible flow graphs in their code, I would have lost
almost everyone around here :-)

BTW, kindly provide the link where I said *ALL* students produce
spaghetti code. Now you're putting words into my post.




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

Forgive me. I now understand that you've got a vocabulary problem here
and that you don't understand the meaning of the term "spaghetti code".
I'll let it go at that.


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.

Yes, I came in with my mentality, based on over 10 year's of teaching
experience, where I've learned some things that work and many more
things that don't work. And one thing that doesn't work is avoiding
teaching students about classical control structures and how to
implement them in assembly language. During my tenure as an assembly
instructor, I've seen what happens when you don't do this, and I've
seen what happens when you do teach them how to implement the control
structures. And the code the students produce is *much* better when you
explicitly teach them how to implement the control structures. That's
just not something you really get a feel for until you've experienced
it *first-hand* in a classroom.

One thing I find so amazing about this newsgroup is how so many people
around here are experts how how assembly language should be taught to
others, yet most of these experts have never taught a single student,
much less a class or several classes of students. And I'm not
particularly picking on you, a *lot* of people around here have such
opinions. Frankly, I had similar opinions before I taught my first
university course; those opinions died quickly when reality set in.
That's why I suggest that you should try teaching a real class
sometime. It's a real eye-opener.



I'm not here to criticize you, Randy, and I hope this comes
across as a little constructive criticism.

But it's *not* constructive. You're pushing two things:

1) Spaghetti coding is okay, let the students do it.
This is just flat out wrong. We've known that since the early
1970s. Both in the classroom and in the real world. Go find some
1960's-era FORTRAN code (or assembly code) and read that if you think
spaghetti coding is okay.

2) You should get to know each student individually.
Great idea, it doesn't scale up in the real world. If all classes
had 20 or few students, you could do this. In the real world,
particularly in the lower-division courses (where assembly language is
usually taught), courses are *much* larger.



Keep your mind open
to others' suggestions. :-)

There is a difference between keeping an open mind and recognizing that
some suggestions are off the mark.

The world isn't /your/ classroom,

Yes, it is. It's *every* instructor's 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.

As you so succiently put it, I am *not* God. Sorry, I can't listen to
everyone. I only have so much bandwidth available. Again, think about
400 students in four weeks.


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.

Really? How many classes have you taught so you can make such a
proclamation?

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

You don't know what you're talking about. Please quit embarassing
yourself.


(2) Each student is an individual and has specific needs.

Yeah, but if you take the entire class has a whole and graph those
needs, you'll find that the majority of the students have very
*similar* needs. Indeed, when you graph it, you'll find that it
typically forms a "bell curve". The "average" students are those that
typically fall between the 30% and 70% regions of the bell curve.
Taylor the instructor to the very similar needs of these students and
you'll have a good class.

(3) You hinder no one by helping those that need the help.

Uh, this assumes that you have an infinite amount of time to help
everyone who seeks help. Reality check for you -- instructors *don't*
have an infinite amount of time available. By helping one person, you
hinder the person who couldn't get help because that time was not
available to help them. And this is why you target your instruction
for the "average" student. The really brilliant students (the 70-100%
points on the bell curve) can pretty much figure out everything on
their own and won't need your help. The average student will
*generally* figure things out from the lectures and other components of
the course because you've geared the course for their typical needs; in
the few instances where they have specific needs not covered by the
class, they can come and see you. And the students at the bottom of the
curve (0-30%) will come and spend a lot of time in your office seeking
help. Some students *definitely* monopolize the instructor's time and
prevent other students from getting the help they need. It's sad, but
I've *had* to send students away in the past because I couldn't get a
point across to them and there were students waiting to have other
questions answered. In an ideal world, this wouldn't happen. But this
is the real world, not an ideal world. In the real world, you want to
satisfy as many student's needs as possible, not satisfy the one's
needs (if that's even possible) even if this means not satisfying a
large number of other students. Or, as Spock says, "the needs of the
many outweigh the needs of the one."



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.

And, believe it or not, there isn't a single book that is going to
explain everything every student needs to know about the subject. Most
books, for example, are geared towards the average student. That leaves
the advanced and slower students hurting a bit.



Sometimes I wonder about the things that go on inside classes.

Try teaching one. Then you'll really know.

I wonder if everyone passes with an 'A' grade, does the college
condemn the instructor for NOT failing someone?

I got in trouble for failing about a third of a class one time (this
was a compiler course, not an assembly language course). I've never got
in trouble for giving everyone A's (that happened in a couple of
special studies course, where I'd typically have five students working
with me).

Does the
college dodaddies EXPECT a certain statistic?

Indirectly, yes. A "C" is supposed to be an "average" grade. At the
schools I've taught at, this seems to have been inflated to "C+/B-",
but the same principle applies. If an instructor consistently has a
high GPA in a course and other instructors teaching the course don't do
the same (ditto for low GPA), some questions *do* get asked.


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.

Is Julienne even reading this at this point?


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.

You are absolutely correct. When I last taught at UCR in 2000, a
typical assembly course had between 60 and 120 students. Once in a
while it got as low as 30 (during an off quarter). Obviously, the
course goes *much* better when you have smaller classes. Alas, the
economic realities don't allow Universities to limit class size.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Book on Assembly
    ... to create their own control structures. ... Some spaghetti is better than some other spaghetti. ... And the spaghetti students write, without having been taught how to ... the classical control structures in assembly language. ...
    (alt.lang.asm)
  • Re: Book on Assembly
    ... Some spaghetti is better than some other spaghetti. ... You'll spot the students that take the easy way out. ... this (as it's such a common thing, ... singly linked lists, ...
    (alt.lang.asm)
  • _Verum Et Factum Convertuntur_ (or: Surprised By Syntax)
    ... Students can't write clean English ... text and strategies for teaching your language to fellow students. ... that they are learning how to marshal arguments in ways that will ...
    (sci.lang)
  • Re: Book on Assembly
    ... HLL-like control structures with CMP and Jcc, ... The students already know HLL-like control structures. ...
    (alt.lang.asm)
  • Re: pre-english... for adult students of english as a foreign language
    ... learning language is part of growing up ... Just doing this in the US are we then, Heron? ... .most of my students have been asians... ... china, another chinese living in canada, and a moroccan ...
    (alt.usage.english)