Re: Book on Assembly

<randyhyde@xxxxxxxxxxxxx> wrote:
Let me tell you what happens when you let the students loose
to create their own control structures. Instant spaghetti! It's
amazing how bad they wind up writing code.

Some spaghetti is better than some other spaghetti. Not all spa-
ghetti is the same. Some might have a better noodle. Some might
have a better tomato. It's up to the instructor to point out and
explain the difference in the noodles and tomatoes. And the very
long winding broken noodle isn't always a bad noodle.

I'll argue with you Randy, not against the structured approach,
and not against teaching the fundamentals, but against the non-
sense 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 hope-
fully every student, some students will be utterly confused and
might not turn in anything to start, but for the moment we'll
assume that every student turns in something) student, you,
the instructor get an understanding of some things in particular.

(1) You'll spot the students that take the easy way out.
(2) You'll spot the students that take a studious approach.
(3) You'll see those that know little.
(4) You see those that know quite a bit.

At this point, you'll have some starting information about the
skills of the students. At the end, hopefully the final project
demonstrates that each student advanced and learned. The
goal is teaching and you need two items to know that you've
taught well. You need a starting point and a finishing point.
The first project and the last project. Never identify the
purpose for the first project as something to demonstrate a
level of advancement, some students will already pick up on
this (as it's such a common thing, that students might come
in expecting such a thing, it must be taught to students training
to be teachers). So the purpose for the first project is for the
instructor to discover the abilities of the students, so tell them
that it will be the ONLY project that is NOT required to get
turned in, just make them write a written statement why they
didn't turn in a project (five paragraphs in length, in standard
scientific writing, with a subject paragraph, three reasons why,
and a conclusion). Have to get them ready for the real world,
whereby if someone doesn't complete a project a written exp-
lanation is required (could even give students a certain amount
of money to start out - fake money, whereby the amount of
money at the end determines their grade).

Expect spaghetti at the start, and expect better spaghetti in the
end, that's the way I see it. A great vegetarian spaghetti gets
the applause, perhaps some eggplant, peas and beans mixed in
with the tomato, garlic, basil, cilantro and a couple serrano
peppers.

From real-world experience, let me suggest that teaching
the students how to implement classical control structures
in assembly language is the best approach. Once they see
how the classical structures are done, *THEN* they can
explore alternative approaches. But without a decent
foundation to build their knowledge upon, the result is
often chaos.

I agree with that. I believe the spaghetti you described offers
more than you acknowledged.

For Julienne,

And as for the topic of the thread, my suggestion for that in-
volves the following...

(1) Many real world examples.
(2) Some virtual examples, simple in nature, which drive home
some very concrete points.
(3) A long set of appendices (mis?). The appendices can be
built one at a time as you go along, or as the final touch. They'll
contain something along the lines of the following (not limited to):
(a) a list of the most commonly used instructions,
(b) a list of the common base data types,
(c) singly linked lists,
(d) doubly linked lists,
(e) functions that do not return anything,
(f) functions that return a simple type,
(g) functions that return a complex type,
(h) an example of a for/next loop,
(i) an example of a while loop, and
(j) some very common macros.

Okay, and now the following represents a sample list of
topics...

I. Introduction
(Keep it simple, short and to the point).
II. A common approach. All software development starts off
with a goal or objective or purpose. Then it requires an under-
standing of that objective and options involved...
III. A simple "hello world" demonstration.
IV. A simple real world example of something quite common.
Perhaps something like a booking software for an airline,
to demonstrate saving a file, reading a file, searching through
a file, loading data from disk to a memory structure. Some
one else can add to what this software should do.
V. Another real world sample, whereby a DLL exists and is
already created, and the goal is explain taking apart the DLL.
VI. An example of simple hex editing software.
VII. ... and so on ...

And then some more examples. The order of the examples
above to be rearranged as applicable.

Hope this helps.

--
Jim Carlock
Post replies to the group.


.

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
    ... that all code exists as some form of spaghetti. ... then the students produce *bad* ... "spaghetti code" implies that the control structures in a program ... decade+ that I taught assembly language at the University level, ...
    (alt.lang.asm)