There is enough that has to be thought about and enough that has to be done a certain way that (in my experience) students don't spend enough time learning how to program well.

Actually, this is one reason why I suggest starting with a sane assembly language, probably in a simulated environment. (My university's using spim for this purpose, although the intro assembly course is well into the comp.sci. curriculum.) The scope of the programs, especially the first programs, are so limited that the students don't have the opportunity to get overwhelmed with detail, so they're free to concentrate on the basics of what they're doing.

Further, programming in assembly gets out of hand so quickly (if you let it) that some good programming practices, like descriptive names (for labels and such), subroutines, even stuff like unit tests are actually emphasized, rather than ignored. I've never seen an introductory programming course taught in assembly, but I imagine it could be very successful at teaching basic programming practices.

It's my opinion that the above that you noted can be learned after the basics with no ill consequences. With a proper helping hand in learning the basics, nothing will have to be unlearned from developing bad habits either.

In my experience, students who have learned to program in "helpful" languages have a difficult time taking over the chores of memory management, bounds checking, and so on when they switch to a lower-level language like C or assembly, because the languages (and, usually, the instruction) hide the workings of the computer to the degree that students aren't prepared (or inclined) to think of memory as a finite resource that must be explicitly allocated and freed, or pointers as things that can point to unexpected places, or strings as having finite length, etc. Sure, this sort of careful programming (really, the issue at hand is resource management) can be learned after the basics, but it often isn't. There is a lot of ground to cover in a standard comp.sci. curriculum beyond the basics without including extra material on basic software engineering.

I feel a need, with plaintext being so poor at expressing the emotions of the writer compared to conversation, to explicitly note that there is no malice in the above and I am very thankful for your opinions.

No worries. :-)

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.