RE: Introduction & Question

> In the Major Havoc source (6502 Assembler, not C in 1981-1983), the code
> is a crazy hot mess (respectfully of course!).

How 'bout I forward this on to Owen? He'd get a kick out of it. ;-)

> It is sort of funny because when I was a teenager, I learned everything
> in Assembly Language (hurray for global variables!) and Object Oriented
> Programming always seemed like a mysterious 'backwards' way of doing
> things. Now that I have been doing OOP for 12+ years,

I think a lot of people forget that doing OOP != C++/Java, etc... (i.e.
"C++ Is just C with classes and variables defined wherever!") Object
oriented programming is a design/implementation methodology, not a
language. Sad that so many <10 year graduates don't know that, but I guess
that's what you get when universities are chasing programming fads. You
can do OO in assembly. It's all in how everything is organized.

> looking back on
> the raw assembly language, I can't even comprehend how to prevent a
> litany of bugs due to overlapping memory blocks, bad offsets or scope
> clobbering for temp variables.... whoa Nellie, it is a totally different
> way of looking at things and not a fun set procedures to try and track
> down problems.

Not as bad as it sounds. I co-authored >1MB of 8051 assembly language for
an OS for a Roland Jupiter 6 and you basically have your support routines
use dedicated globals. Just set up a set of rules for how you use
registers and memory locations and avoid using them for the wrong purpose.
But as soon as you add in multiple people, I can see it getting ugly fast.

> We all have mostly lived in both worlds... it will be interesting to see
> how the younger generation of programmers deal with that old code
> someday! I wonder if they even will? It may be a lost art at this point
> ehh?

<rant>
Oh, no, didn't you hear? Pointers are too hard. That's why Java eliminated
them. Just let the garbage collection routines work in the background and
suck up additional CPU power when you don't want it to. Don't pay any
attention to what's going on under the hood.

Why yes, I just was handed a C++ program that had several modules
exceeding 10,000 lines of code, with procedures >3K. Why do you ask? ;-( I
also was asked if we could add a JVM to our embedded system. And no, it
didn't occur to them that it would exceed the available flash space.

Lost art indeed, Jess. I swear that if we forced everyone to work in an
assembly language boot camp before giving them a high level language, we'd
have 90% less programmers out there. I often get disgusted by the thought
of how much extra CPU and electricity is used up by all the CPU burned by
bloatware and interpreted languages (I'm looking at you PHP and JVMs)
</rant>

I guess on the flip side, it just means job security for us embedded
systems guys. And yes, I'm grizzled. Now get off my lawn... ;-)

-->Neil

----------------------------------------------------------------------------
C. Neil Bradley - Excessive process falsely elevates the incapable and ties
                   the hands of the exceptional.
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Mon May 21 03:38:45 2012