Skip to content

Rough Book

random musings

Menu
  • About Me
  • Contact
  • Projects
    • bAdkOde
    • CherryBlossom
    • FXCalendar
    • Sulekha
Menu

The State of Computer Engineering

Posted on January 2, 2009September 9, 2009 by vivin

I was having a conversation with a few good friends (old college buddies, and fellow nerds) over a couple of beers a little while ago. We mainly reminisced about certain key classes we took while we were at ASU, and also about the state of CS and CSE graduates today. Indeed, the very nature of the degree. First, a little bit about those key classes that we took and still think about. These classes are CSE 225, CSE 421, CSE 423/438, and CSE 521. I wasn't able to take CSE 423 and 438 because they were discontinued by the time I had completed the required prerequisites. But I was able to take the other three. All three classes deal with assembly programming. Assembly programming is the lowest level of programming there is. You directly control the CPU by sending it instructions. These instructions are actually decoded into a bit-pattern, which essentially translate into a series of on and off signals that travel to various places within the CPU (or even associated memory, I/O, etc.) and make it do cool stuff. At this level, you don't have any of the niceties of higher-level programming-languages. There are no variables. There are no function parameters. There is no easy way to do I/O. Data can sometimes be program code and program code can sometimes be data, depending on your point of view. It's a highly restrictive and immensely liberating and powerful environment at the same time. It takes a lot of effort to code in assembly, and much more effort to code well.

My introduction to assembly programming began with CSE 225. The class was taught by Lance Johnson and dealt with the Motorola 68HC11 (now produced by Freescale Semiconductor). I was pretty nervous about the class because I had heard how hard it was. As it turned out, yes, the class was hard. I put a lot of time into the class, and in the end it paid off. I got an A. The next class after CSE 225, was CSE 421 and this was taught by Dr. David Pheanis, one of the best professors I've ever had. Lance taught CSE 225 the same way Dr. Pheanis taught CSE 421, although it wasn't as difficult. Both classes had "shotguns" (unannounced quizzes) and lab demos. In both classes you had to document your code thoroughly. In addition, you had to demo your code to the TA's and every time you failed a demo, you would have 5 points knocked off your score for that lab. Oh, and in addition you were also graded on the efficiency of your lab solution. Embedded environments are usually sparse when it comes to resources, so getting your program to be small and fast is very important. Your efficiency score was calculated against the professor's score. For every byte that you were over the optimal solution, you get one point taken off your lab score. If you ever beat the optimal solution, you got additional points. Pretty exacting standards.

In CSE 421, it was even harder. Dr. Pheanis would grade you on time on some of the labs as well. You also wrote code on the Motorola 6800, which was the predecessor of the 6811. As a result you were limited on the number of registers you had, which made it harder to write code (well, efficient code). You also had to have a very good amount of documentation. Each lab had a General Overview, User's Guide, and Internal Overview. Any subroutines in your lab had to have its own User's Guide and Internal Overview. Stack usage had to be properly documented. Logical groups of your assembly code had to be extensively documented and you had to explain the what, how, and why of your code. So if your program wasn't adequately documented, you lost points. Our final lab involved implementing an Asynchronous RS-232 receiver and transmitter driver for the 6800. At the end of CSE 421, I learnt a lot of useful things. For one, I learnt how to write efficient code (something that has carried over into my high-level programming) and I learnt how to document my code really well. I also learnt how to be a good programmer.

The last class I took with Dr. Pheanis was CSE 521. You could register for this class, but more often than not, Dr. Pheanis invited you to take the class if he thought that you were a good student, and that you could handle the course load. I was privileged enough to be invited by Dr. Pheanis. In CSE 521, you write assembly code for the Motorola 68000. The 68k is a beautifully designed processor. The instruction set is almost completely orthogonal, and in general, it was a complete delight writing code on it. On a side note, writing on the 68k spoiled me to the point where it was impossible for me to pick up x86 assembly. The design is just atrocious. Anyway, the class was hard. I took it during my final semester at ASU, and I had two other classes (that I actually needed to graduate), but I spent the most time on CSE 521. In addition to the usual stuff you got graded on in CSE 421 (demo-passing code, efficieny (time and speed), and documentation) you were also graded on English grammar. I remember getting my first lab back and finding red marks all over it. Granted, I had done a little better than my classmates. I've always been comfortable with the written aspect of the English language and I thought I had a decent grasp of the language. Well, it wasn't as decent a grasp as I had thought. I was introduced to problems such as "it or this without proper antecedent", "the scope of 'only'", and "proper hyphenation". Oh, there was also the infamous "Avoid ugly passive voice" stamp. Examples of such problems:

An "it or this without proper antecedent" grammatical error occurs when there is ambiguity in a sentence about exactly what "this" or "it" is referring to. For example, "Susan bought a dress and a hat. It was green." In this example, we can't say what "it" is referring to; it could be the dress or the hat. The sentence should be rewritten: "Susan bought a dress and a hat. The hat was green." The "scope of only" is an interesting one. Consider the following sentence: "John only drinks water." You might think it means that John only drinks water and not any other kind of drink. Actually, the only restricts the scope much more than that. What the sentence actually means is that John only drinks water and does nothing else. He doesn't eat, sleep, sit, stand or do anything else for that matter. He only drinks water. The correct version of the sentence is "John drinks only water." In general, you want to use "only" as late in the sentence as possible. Hence, the "scope of only". Then there's "proper hyphenation". You generally want to use hyphens with compound nouns and adjectives. For example, "dining table", "fish tank" and "operating system" are compound nouns whereas "black and blue" and "extremely hot" are compound adjectives. When you use an adjective to describe a compound noun (or vice versa), you need to properly hyphenative. Otherwise, the meaning of the sentence will be ambiguous or nonsensical. For example, consider the colloquial expression "It was a cold ass day", meaning "It was a really cold day". Does it mean it was a "cold-ass day" (compound adjective "cold-ass" with noun "day"), or does it mean it was "cold ass-day" (adjective "cold" with nonsensical compound noun "ass-day")? Properly hyphenated, the sentence should read "It was a cold-ass day".

You might wonder why English grammar is so important in an assembly programming class. Programming is more than just writing code. Once you write something, you (or someone else) needs to maintain it. So it is generally helpful if you can tell what your code is doing. This is especially important in assembly programming where it is not immediately obvious what the code is doing. I remember how Dr. Pheanis used to say that Engineers generally have terrible documentation skill. This is very true. I cannot count the times I have scratched my head looking at code I only wrote a few months ago, trying to figure out what exactly I was trying to do.

Now to the original point of my post. Larry Wall (creator of Perl) along with Randall L. Schwartz and Tom Christiansen outlined the three virtues of a greate programmer:

  • Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
  • Impatience - The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
  • Hubris - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

In addition to the three listed above, I'd like to add another one: Passion. This is the virtue that makes you like writing code. This is the virtue that makes you sit up till 3 A. M. in the morning hacking out a Mandelbrot-Fractal Generator or an artificial-life simulator just because you think it's a cool thing to do. This is the virtue that makes you crash your box because you decided to do something bleeding-edge and incredibly unstable and dangerous just because you wanted to. This is also the virtue that gives you the desire to learn; the urge to acquire newer and better skills and to be a better programmer. Passion, is unfortunately in short supply these days among most programmers that come from college (or at least, ASU). In part, I blame the administration itself. When I was in college, the department tried very hard to force Dr. Pheanis out of his class, ostensibly to "modernize" the curriculum. Their rationale was that the processors used in Dr. Pheanis' classes were "outdated". Apparently they weren't able to grasp the concept that assembly programming is not about using the latest and greatest processors, it is about learning the fundamentals. Dr. Pheanis' last class was in spring of 2004. He's a professor emeritus, and no longer teaching at ASU. ASU's current computer engineering curriculum doesn't have many interesting courses, for example, as I found out from Marc, ASU isn't offering a compiler-design course anymore. In an urge to make the course more "modern", I think a lot of soul has gone out of the program. Just taking all the classes doesn't turn you into a Computer Engineer or programmer. It's true that I learnt a lot of theory and a lot of other useful stuff from the classes at ASU, but a lot of times I went out of my way to learn things on my own. When I started college, I didn't know the first thing about Unix. I knew how to write code (I wasn't great... yet 😉 heh), but that was it. During my first semester I taught myself how to work on a Unix system. I learnt how to use vi and how to write shell-scripts. Over the years I started teaching myself more and more stuff - I taught myself Perl and PHP, and picked up the finer points of web development. I taught myself how to set up and administer a FreeBSD server. What also helped me a lot was that I was around people who found these kinds of things as interesting as I did. The classes and professors fostered the type of environment where you felt inclined to learn more than just what the curriculum offered. There are graduates these days who don't think there are other development environments besides the GUI. I was writing code on a Solaris system when I was in college. My development environment consisted of the commandline and vi. It's actually only recently that I've been using IDE's (I hadn't really used an IDE since Borland's IDE for C++, and that was during my junior and senior years of highschool), and while I definitely find that they enhance productivity (especially for large projects), I feel equally at home hacking on the commandline. There are graduates today who don't know anything more than what they're taught at college (I like to call them "cookie-cutter programmers"). They know Java and/or C++ (and perhaps Lisp, and C). They know data structures, and maybe they've heard of Linux. But they really don't know anything besides what they've been taught (I don't think all is lost, however, there still are graduates who do more than just the curriculum - who are passionate about the field).

I guess what I'm trying to get at, is that I think CS programs at should should foster an environment of self-discovery, self-learning, and exploration. Unfortunately, I find that this is not the case with ASU's CS program these days. Compared to what it was when I've gone through, it just contains a bunch of stock classes that have replaced the older ones. The reason? Supposedly "accreditation". In fact, I remember feeling extremely disappointed when Google closed their doors in Tempe. The Google office was very close to the ASU campus. Their closing told me that they weren't able to attract good talent from ASU, and that's just disheartening. Perhaps the heads of the CSE department at ASU should be more concerned about giving students good, practical knowledge, and teach them how to be better Computer Engineers and Programmers than just being concerned about accreditation.

7 thoughts on “The State of Computer Engineering”

  1. sheehan says:
    January 2, 2009 at 10:31 pm

    really good post. funny you mention, Lance Johnson apparently he is legendary. I took 225 w/ Deborah Calliss at ASU and it was your basic assembly class. That summer I was looking for classes to take, and I saw L. Johnson teaching 225 at MCC (I learned of him from Nasser and wanted to see what he’s all about). I pretty much signed up for an ass-whooping, but really learned assembly at a whole new level.

    though I agree with you that the current state of computer science has definitely made things easier for new graduates like me (2007) – programming is at a point where it can deliver instant business value. you’ve got frameworks, language enhancements, and tools that automate a lot of things for you. this allows you to focus more on architecture, design, and customer requirements. money talks, and at the end of the day you are satisfying your end user.

    Reply
  2. vivin says:
    January 3, 2009 at 4:40 pm

    Hey Sheehan,

    Lance Johnson is a really good teacher. Yep, that’s the same way I felt about his class. You really do sign up for an ass-whooping, but you end up seeing assembly in a completely different light.

    I agree with the point that programming does deliver instant business value. But I think that deals more with consulting than the actual application of programming. You’re actually one of the few recent graduates that I’ve seen who actually know what they’re doing and why they are doing it. People who like Computer Engineering and programming because they are passionate about it.

    I guess what’s also missing these days in the program is that you don’t "learn to learn"; I feel that’s very important in a programmer.

    Reply
  3. Ahmed says:
    February 24, 2009 at 10:00 am

    Aah…I had CSE 225 with Lance Johnson as well. I barely passed CSE 225 and CSE 421 (With dr Pheanis) with C grades!! I had CSE 422 with I think Dr Woodfill!! Sweet memories of VAX labs and CRT terminals!!! I miss them!!

    Dr. Pheanis used to create a special bond in his class. Very decdicated to the students. He will be missed by students.

    Another area where most computer science schools (including ASU) are shrinking or not paying much attention to is use of scheme/Lisp for teaching computing. Pointers can be avoided now if someone starts taking courses with Java – another thumbs down. I think we had only one course where little bit of Lisp and Prolog were used – can’t remember the course number now.

    Anyway, as Sheehan said now-a-days we have code-producing factories. There is not much writing (of codes) going on. That is how the world is 🙁

    Reply
  4. Russ Dill says:
    February 24, 2010 at 9:23 pm

    I was at ASU from 98-02 and really enjoyed the classes that Pheanis’s and Johnson’s classes offered. My in-laws are moving so my wife and I collected a bunch of her boxed school papers. Mixed in, I found some very familiar looking papers with the familiar word MUDBUG throughout. I discovered that my father-in-law took Pheanis’s class on the M6800 in ’79, the year I was born. Wow.

    Reply
  5. vivin says:
    February 24, 2010 at 9:35 pm

    @Russ Dill
    Wow, that’s a neat story! Have you talked to him about the classes? I wonder what it was like back in ’79!

    Reply
  6. Dave WIchers says:
    December 1, 2012 at 8:46 am

    I took like 5 classes from Dr. Pheanis during 1984-1987, and was also his TA for several classes. He was definitely the best teacher I ever had in college. And he ran the classes exactly the same way when I was there, code size, correctness, and documentation were the measures of success. Brutally simple formula, but forced you to think really hard. I’ve been doing software work for 25 years now and that background has served me well my entire career even though I never wrote another line of assembly after ASU. An awesome foundation to start off with.

    Reply
  7. vivin says:
    December 13, 2012 at 1:52 pm

    @Dave WIchers: Good to hear from an old student of Dr. Pheanis! I completely agree with your points. I although I don’t live in that world (assembly), the background, foundation, and experiences it provided me is something I still use every day.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Archives

  • February 2023
  • April 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • June 2017
  • March 2017
  • November 2016
  • August 2016
  • July 2016
  • June 2016
  • February 2016
  • August 2015
  • July 2014
  • June 2014
  • March 2014
  • December 2013
  • November 2013
  • September 2013
  • July 2013
  • June 2013
  • March 2013
  • February 2013
  • January 2013
  • October 2012
  • July 2012
  • June 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • July 2011
  • June 2011
  • May 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • August 2008
  • March 2008
  • February 2008
  • November 2007
  • July 2007
  • June 2007
  • May 2007
  • March 2007
  • December 2006
  • October 2006
  • September 2006
  • August 2006
  • June 2006
  • April 2006
  • March 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • February 2005
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003
  • November 2003
  • October 2003
  • September 2003
  • July 2003
  • June 2003
  • May 2003
  • March 2003
  • February 2003
  • January 2003
  • December 2002
  • November 2002
  • October 2002
  • September 2002
  • August 2002
  • July 2002
  • June 2002
  • May 2002
  • April 2002
  • February 2002
  • September 2001
  • August 2001
  • April 2001
  • March 2001
  • February 2001
  • January 2001
  • December 2000
  • November 2000
  • October 2000
  • August 2000
  • July 2000
  • June 2000
  • May 2000
  • March 2000
  • January 2000
  • December 1999
  • November 1999
  • October 1999
  • September 1999
©2023 Rough Book | Built using WordPress and Responsive Blogily theme by Superb
All original content on these pages is fingerprinted and certified by Digiprove