Winter break plans

I've actually gotten all A's again so far, with only my cryptography final to go. Quite surprising to me, but I can't really complain. Unfortunately, I tend to get less productive instead of more productive during break (that's what it's called break, I guess?), even though I have no schoolwork to bog me down. In any event, my to-do list:

1. Sleep.
2. Study for the Western Civilization I CLEP exam. I need two more gened classes (6 credits), and this exam will satisfy the requirement. I only need a 50%, so I can't imagine myself studying very hard. Hope it doesn't come back to bite me.
3. Read The Little Book of Semaphores, or at least some of it. I'll probably be helping design a class on concurrent programming next semester, so I figure it's best to advance my knowledge as best I can so I'm not useless.
4. Sleep.
5. Look into more web programming. I got bored this week and started trying to scrape together a new template for a blog; you know things are going bad when I start writing HTML and CSS. My hope is to do some stuff with Django, a Python web framework. If no other ideas come to mind, I may end up replacing my blog with a Django site. I haven't completely ruled Pylons out yet, since I still subscribe to the mailing lists, but since the Django book was published recently, hopefully it will provide a better source of documentation. And hopefully the book will be released online during break, or I'll be sad.

I've unfortunately put language-related things behind me for now. If I'm looking for an industry job, it probably isn't very marketable.

The difficulty of Lisp

An blog post on the difficulty of learning Lisp recently appeared on Reddit, which argued that Lisp was actually not very hard to learn. Unfortunately, to be honest, the reasoning totally sucks.

I think the "Lisp is hard" idea is general bunk. It’s different and looks funny (but, hey, if you can stomach C++, what can’t you take!) but getting started in Lisp is no harder that any other language. In fact, its easier to get started in Lisp than it is in programs that require a separate compilation step.

Of all of the points to argue why Lisp would be easy, this is certainly not a very good place to start. A hello world application indicates nothing about the difficulty on learning a language. Well, almost nothing. Java's hello world is often cited as indication of how difficult it is for some to learn Java, but I don't think the converse applies. I do agree with the author, though. It's going to take a lot of work of some sort to start convincing people otherwise. Mark Guzdial, a long-time teacher now at Georgia Tech, wrote a post about the best paradigm for teaching programming, saying:

Supporters have argued that a functional approach is most like mathematics (and is thus more familiar) and that non-mutable variables lead to more easily maintained software, are easier to understand, and are more likely to be provable. A paper at ESP by Michael Eisenberg and Mitchel Resnick showed how hard functional programming is for students. If the students are comparing functional programming to mathematics, it’s not obvious and even if it’s happening, it’s not clear that it’s helping.

Unfortunately, the article was published in 1987 and isn't even available at ACM's digital library. Funny enough, the five comments at the time of this writing all agree that Lisp is not hard. The general consensus seemed to be that Lisp makes other languages hard, that learning Lisp first would make other languages harder. I find this somewhat difficult to believe, and very subjective at best. It may certainly have an impact (to a degree) on what language you prefer, but as to increasing the difficulty of learning, there probably isn't much research in that area. It's similar but more radical to the debate over whether learning object-oriented programming before procedural programming (Java, C) is better.

Indeed, some of the resistance to learning Lisp is probably FUD of some sorts. It's probably also somewhat related to many universities' reluctance to teach a language that isn't used in the industry, which doesn't use Lisp because universities don't teach it, ad infinitum. However, it's certainly unfair to argue about ease of programming with hello world programs.

My first F# program

In previous hopes of getting an interview with the nascent F# team (which I obviously did not get; sad faces all around), I started adding F# blogs to my feed, including a former C# PM who I had the privilege of working with during my internship and ICFP 2006, Luke Hoban (not Luke H on my links). Jomo Fisher, a new developer on the F# team, posted a small challenge to "pivot" a list of lists in a small number of lines in any language. The goal is to be as concise and clean as possible, while beating his solution and a yet-to-be-posted solution, which are 9 and 4 lines of F# respectively. I came up with my first F# program after awhile (it looks like I just copied someone else's on the comments list, but comments are moderated so they weren't all there), which was kind of fun:

let rec pivot(l: 'a list list) =
    match List.hd l with
        | head::tail -> [for sub in l -> List.hd sub]::pivot [for sub in l -> List.tl sub]
        | [] -> [];;

Possibly due to my amateurism in functional programming or unfamiliarity with F#, these four lines took me quite awhile to figure out (more than an hour). Of course, reading the code is easy enough; I wonder if functional code exhibits hard-to-write, easy-to-read behavior in more than just this case. Of course, my solution is not quite the best, since my pattern matching operates on the head of the list. It's probably better to match the list with []::_ and _, which was someone else's solution.

Imperative code for this in the comments have been predominantly larger than 4 lines, with a C# with LINQ solution being the shortest. What other tricks can people come up with? I think the zip use in Python is interesting. It accomplishes the problem in one line by unpacking the list of lists and sending it to zip, a built in function that does transposition. Of course, zip is basically the problem objective so it seems kind of like the cheap way out; the use of Python's * operator to unpack the list makes it quite easy to do; F# has List.zip, but I have no idea if it can unpack the list like Python can.

In other news, I finally got F# to work with Mono on my Linux computers; turns out all that I needed to do is install some libraries.

On C# and properties

I flew out to Seattle again this weekend for afternoon tea with Microsoft's CLR and C++ teams. The C++ developer I met was an interesting fellow, having worked on MSVC++ compiler for over 14 years and other C/C++ compilers for even longer. I've never seen someone so passionate about compilers, especially not for C++, but he seemed to take the challenge of C++ and transform it to pure enjoyment.

At one point during our discussion over Thai food for lunch, we started talking about characteristics that constituted "high-quality code", as well as topics in programming languages. Of course, there was no way I could lie my way out and say that C++ is my favorite language—it's probably among the least favorites—but my mention of C# led to some discussion about why I liked C#. I mentioned that C# was basically "Java done right", since Java is pretty clearly a direct predecessor to C#. Of course, no programming language is perfect, and he probably would have thought I was an opinionated jerk if i had said C# was.

Instead I decided to bring up something that I'd been thinking about for the past few days, with our software engineering team to blame. Essentially, I thought that properties should be able to encapsulate private variables properly for maintainers/fellow developers. Obviously they hide private variables and define the interface for designers of other classes, but for the designers of a given class, encapsulation is "broken." The maintainers of the code have two ways to access data (directly through the private variable and through the exposed property), which leads to some unintended problems:

1. Finding references to a variable is separate from finding references to a property. The case where this is necessary is probably rare, at best. This is demonstrated by the popular use of properties that are simply one line get/sets, which is no different than setting the private variable directly. Removing the private path of access would eliminate this problem, which is an irritation to anyone who might use "Find All References" in Visual Studio, as well as any tool that may perform static analysis on C# code.
2. If a property does anything besides a one line get/set, private access to the variable means some code that wasn't executed probably should have been. This was colorfully illustrated in our code in which a property had a multi-page set method (which arguably shouldn't have happened, since properties are supposed to be light). Any single incorrect access to the private variable would meant lots of code feeling lonely and would have resulted in a rebellion that would probably bring the program down.

This is a problem that can probably be solved by simply prefixing the private variable with something (like _ or m_), but I can't say I'm a fan of that solution, and it still appears on IntelliSense. I tend to make the capitalization of the first letter the only difference (private members being camelCase and public being PascalCase) and steadfastly believe that prefixes are ugly. Of course, this is probably the only solution without changing C#, so I may have to adopt it in the future, but what fun is not changing C#?

The solution that I suggested that I hadn't completely thought through was for C# properties to be able to embed variables in them. C# properties can only have get/sets inside of them, but consider the following code:

public DateTime Date
{
    DateTime date;
    get { return date; }
    set { date = value; }
}

I think this provides an interesting, additional level of abstraction. If the date variable in the Date property is local to the property, it prevents public access of any kind to it; all access must go through the property. In a sense, you're almost creating a new class to wrap around the data (you can't actually do this in C# since you can't overload the = operator). This means all reference searches would have to be through the property, which fixes both problems I listed above. Although it looks kind of funny, I think it would be a backwards compatible change, since the private variable could theoretically still exist inside or outside the property, depending on the need to access the private variable directly.

A moment's respite

Time to take a break from real-time Java. Having worked on our programming languages assignment for most of my waking hours in the past two days, a lot of stress and frustration has built up, and something needs to come out. Unfortunately, I don't need to use the bathroom, so I guess I'll be regurgitating what I've been thinking about in the past few days. This happens to be how not to engineer software.

Our software engineering class has thus far probably taught me more things that are bad practices rather than good. Unfortunately, these practices reflect upon just how bad our development process actually is when executed. Here they are, in no particular order of importance:

• Using version control without knowing how to use version control. Everyone knows that version control is necessary, especially for larger projects. To argue otherwise is essentially arguing with a brick wall—nobody cares. Unfortunately, knowing that version control is necessary still gives little incentive on how to use version control proficiently. I'm not here to give a lecture on how to be a version control expert, because undoubtedly I'll be wrong about something. However, it's amazing how some people in Computer Science at the senior level simply don't "get" version control. Our department steadfastly believes that teaching tools is a waste of time—such is the job of C&IT. At this point, I'm almost convinced that they're wrong, to some degree. One teammate assumes that checking out a new repository and copying all of his files over before committing is a good way to fix conflicts. This is obviously a very bad idea, especially if you have files that are out of date, and it just so happened to be the case. His solution? Blame Subversion for everything. The problem is between the keyboard and chair. Seriously.
• Not communicating properly. When an e-mail goes out to your customer, all of the relevant people on your team should receive a copy of that e-mail. For us, that's everyone on the team. There's no reason not to, and leaving out people results in very one-sided communication.
• Not listening. When a teammate has something to say, learn to listen. Interruptions are not usually helpful. Neither is waiting until the teammate is done talking, but not listening. This really shouldn't have to be mentioned, but this is actually a common occurence. Listen to the other person, and then if he/she is wrong, then explain why. Interrupting because you're 200% convinced your method is infallible is unacceptably rude and arrogant.
• Project tracking instead of project leading. A recent article on Reddit summarized the problem nicely. A team leader is not responsible merely as a gateway to the customer; a leader is ultimately responsible for keeping the team accountable and heading in the right direction. Can't do that? Please don't be a team leader. You may get this fuzzy, warm "leadership" experience to put on your resume, but the result will be that your team will fail.
• Allowing feature creep. This seems to be a fairly common problem. On a deadline as short as ours (one semester), it's vital to stick to the defined specification. "I think ______ would be nice" is completely unacceptable. This will result in a traffic jam and a failure to complete the project on time.
• Not using an issue tracker. Humans are typically not very good at context switching. Typically, when you find a bug, the best way to deal with it is to file a bug report. If you decide to fix the bug immediately, unless you were specifically looking for the bug, you're context switching away from what you were previously doing, which can end up being quite a distraction.
• Lack of in-code documentation. This is probably something that virtually all CS majors at Purdue are guilty of. When we're working alone, there's no reason for us to comment; we're all brilliant geniuses that always retain understanding of what our code does. Unfortunately, this brilliance doesn't transfer when you work on teams. In-code documentation is important for quick reference. In addition, many languages support extracting the documentation out from code into various document formats, which adds even more benefit to code documentation. This alone should be a good reason to document function headers. Nobody is asking for an essay, but at the same time, nobody understands what your function does.

All in all, this is a very random assortment of pitfalls I've seen among my software engineering team. Some of these are more easily corrected than others, but sometimes I wonder if it's even worth it, with so little time left.

Ah, time. Where did it go? This semester feels like it's gone by faster than the rest, perhaps due in part by the post-graduation stress that I'm experiencing. I'm flying out to Google for an on-site interview on Thursday; Microsoft has invited me to an on-site interview, but I don't know when; grad school applications are still looming over my head. It was probably a bad idea to take three CS classes this semester, of all semesters.

Gutsy, Compiz oddity

I got tired of Gentoo on my installed laptop, so I dove in for the Gutsy RC instead. I like the changes from Feisty, but if there's one thing that seriously bugs me, it's the alt-tab/application switcher functionality. A lot of times I use alt-tab/alt-shift-tab for quick switching, but Compiz seems to like to do all sorts of flash fade, opacity, etc. effects on it, which is rather distracting. I turned up the brightness to 100% to stop the fading, and it's less distracting, but not by much.

For some reason, the beta also shipped with alt-shift-tab broken (switch to previous window in the list). CompizConfig wasn't very helpful in letting me bind it, either, so I looked to gconf-editor to solve my problems. Funny enough, there was an entry under apps.config.plugins.switcher.allscreens.options named prev_key that was set to alt-shift-tab. Strange. There was also a prev_button entry that was set to "Disabled", so I changed that to "Tab" and it works now. It's rather odd that both fields exist. I think prev_key should be the proper name (obviously I'm not alone, since someone set it instead of prev_buttom), since there's a next_key and no next_button. It's also odd that I couldn't figure out how to set the shortcut in CompizConfig. Perhaps I'm just stupid.

The freedom of speech fiasco

A recent turn of events at my former high school have evolved into quite a fiasco as of late. Apparently a video of "scuffle" (as worded by Indianapolis TV news) was posted online, which resulted in the people being in the video being suspended. Unfriendly words were directed at the school administration through Facebook, which somehow reached the administrators themselves—this resulted in more suspensions, which caused even more uproar. Someone reposted the video on Youtube and got suspended as well. A Facebook group was created by a student at the high school protesting all of the recent decisions made by school officials with respect to freedom of speech; this group seems to have a fair amount of students in it, reaching almost triple digits. Of course it's incomparable to those "hey guys I want to make a group with a million people in it", but for being the smallest of the four high schools around here, it's a fairly large percentage of high school students involved.

Apparently this chain of events was made a top story on the local news, and made it to Indy news, so I guess it's no small thing. Since I'm obviously no longer attending high school, it's difficult to get a crystal clear picture of what's going on, but from the picture painted by the media and my brothers, who are attending the high school, the situation is just a continual stream of terrible decisions, and not just from school officials.

The whole thing allegedly started due to a video being posted online. To whoever did this: why on Earth did you think this was a good idea? Are fights cool at school now? Get kicks out of watching your angry peers assail each other? That's really cool. Hilarious. Grow up. I don't care what actually happened the video or where it happened; being pedantic about the school code of conduct isn't my goal. Hell, I'll readily admit that I never read that code. Neither did most people who graduated with me. Most of us were smart enough to know that if we simply behaved, then everything would be cool. Getting feel-goods off of a video like that sounds rather juvenile to me. A video of a school fight isn't going to be a blockbuster that makes you a millionaire and a high-profile film maker, either. Maybe you weren't suspended for speech; maybe you were suspended for being stupid.

Of course, no matter how stupid I think posting the video was, I think suspending the person(s) who did so is just as bad, if not worse. The school should know better; we're humans and high schoolers are young humans, typically more prone to error. If school administrators suspended someone every time they did something stupid, the school would be pretty empty. Remember that cliche, "Don't shoot me, I'm just the messenger"? You just shot the messenger. This isn't Sparta. Please stop shooting messengers.

Some students were also suspended for making derogatory comments about school officials, including the vice principal, who was around when I was still in high school. Oops? I guess high schoolers don't know much about diplomacy. The previously linked Indy news article quoted a student, saying:

I called him an obscene name and he called me into his office and he told me he hated me.

That's a great story, right there. Probably one that'll last for generations to come. Okay, personally, I think that it sounds ridiculous. I'm not sure it could sound more ridiculous than it does. I really don't think that a school official would say "I hate you" to a student (followed by a one day suspension), but maybe times have changed. I guess maybe high schoolers were looking for full disclosure and got it straight on. Free speech aside, I don't know why high schoolers feel like they shouldn't be held responsible for what they say. People can get fired for saying stupid things while representing an organization. Granted, these people are typically people with a fair amount of power and responsibility, but that's exactly the point.

But then again, was a full-blown suspension really necessary? If there's anything I learned from my years of being a staff on a MUD full of kids, it's that the best way to avoid overreacting is to ignore what people say. This entire realm of school ethics is apparently a moral gray area (which needs rectification), and the decision made here clearly had an undesirable reaction. The school should probably be the second avenue of teaching kids how to behave, not the first. If a parent grounds a child for misbehavior, I kind of doubt that the entire high school would get up in arms about it. Of course, that means that a child's parents would have to actually care; this is sadly not always the case.

Both news articles indicate a lack of disclosure from school officials regarding the matter. Why is that? Perhaps they've realized that they've gotten themselves into a pickle and have no easy way out. On the other hand, students have been fairly vocal about it, who seem convinced that they're completely right. However, maybe the students aren't as sure of themselves as they seem. The freedom of speech group created on Facebook was made by a freshman at the high school, and it's interesting how the group has progressed. Or has it? The group administrator has blatantly deleted posts that he didn't agree with. Oops. Sounds like a familiar story to me. It's even worse, because this is true censoring.

A few things probably need to happen in order for this situation to settle down. First, either the school administration should stop holing up in their offices and start talking to the press. They should have nothing to hide, apologies not withstanding. The school needs to make policies that pertain to "free speech" on the Internet. Whether or not they're good policies will be tested in time and possibly in court. Kids need to stop believing that they know what's best. The previous paragraph is a prime example of a good idea gone wrong. Sorry, you are still in high school, and believe it or not, you probably lack the wisdom that your elders have. I flew under the radar in high school, and I still look back on high school wondering how I was so silly. And stop posting stupid videos on the Internet. We have lots of those as it is.

A source of happiness

Recent developments by Aady and Rick, who were working this weekend on reverse engineering the servers that ran Silencer resulted in a played game by Rick (who dropped), DarkProdigy, and me. This game was one of my favorite games years ago, but got shutdown when WON.net shutdown. Being able to play a game, even if it was hosted by someone on dial-up, has made my weekend. See Arsia-Mons forums for more.

On advertising and Internets

Slashdot had an article titled "The Morality of Web Advertisement Blocking" posted today. In essence, it was a followup to another Slashdot article talking about how some websites were blocking Firefox users from visiting their site, due to the seemingly common use of the Adblock Plus plugin. The question posed was:

Whereas TiVo users freeload on the relatively fixed broadcasting costs paid by TV networks, users of web ad-blocking technology are actively denying website owners revenue that would otherwise go to pay for the bandwidth costs of serving up those web pages. If the website designer has to pay for bits each time you view their website without viewing their banner ads, are you engaged in theft? Is this right?

The response was probably all to expected; most people shot down the idea of comparing web advertising to television advertising for one reason or another. There were a few people who seemed to seriously consider the question, but the majority of the crowd seemed to learn towards the attitude of "I download what I want." I can't say I entirely agree, but I definitely think the "why is Firefox blocked" website is retarded. At best, I think most websites that use "myth" or "cult" in a demeaning way tend to be FUD. I mean really. The Firefox cult? We worship the Firefox god, lord of all the Internet.

Many people seemed to think that advertisers have no business on websites that they visit, since it's their bandwidth, and they should do what they want with it. In some cases, I think this is a reasonable argument; for example, when viewing sites from a mobile phone, having advertisements seems typical unreasonable. Do they really have a right to complain if they're on a cable line, or something like it? I don't really think so. Ads might "take more bandwidth," but this argument is ridiculous for, say, AdSense ads, which are simply text.

Others say that advertising online is a flawed business model, since you're requesting all of the information you want, as opposed to TV, where you get what you get. This seems like kind of a lame reason, but I have no real marketing background. A lot of big sites seem to advertising (Engadget, for example...and Google) as a source of revenue. To claim that this isn't a legitimate business model is basically saying that many of these sites shouldn't exist. Can you imagine what the Internet would be without Google? They've been around long enough that I can't really remember what the Internet was like back then, except the whole frames, animated GIFs, etc.

There are other interesting posts, but I'm not really here to rip on people for disliking ads. Heck, I dislike ads. Only a weirdo would like ads. I still don't use an ad blocker, though. I actually had a conversation with a friend last night about it:

Not Me (8:25:56 PM): whoa, an ad in my firefox
Me (8:26:03 PM): ruh roh
Not Me (8:26:06 PM): that was actually fairly startling :O
Me (8:26:54 PM): I don't actually use an adblocker heh
Not Me (8:27:15 PM): que?
Me (8:27:30 PM): I see ads quite often in firefox
Not Me (8:27:52 PM): why no blocker
Me (8:28:00 PM): lazy
Me (8:28:03 PM): I don't really use plugins
Not Me (8:28:33 PM): :D
Not Me (8:28:46 PM): adblock plus updates its own blacklists and everything
Not Me (8:28:52 PM): literally like 3 clicks and you're done forever :I
Me (8:29:01 PM): I know
Not Me (8:29:04 PM): i haven't even thought about it in months
Me (8:29:04 PM): that's the sad part of it all
Not Me (8:29:04 PM): kay
Not Me (8:29:06 PM): lol
Not Me (8:29:16 PM): if i were near you i'd come to your house and do it for you
Not Me (8:29:20 PM): because that's just pathetic :-(

Yeah, the secret's out. I'm really, really lazy. Okay, that wasn't really a secret. Also, that conversation has practically nothing to do with anything, I just wanted to say that I don't use an ad blocker. As far as text ads go, I don't really mind them. I've actually seen interesting AdSense ads (okay, maybe once...maybe). I don't think anyone has a right to complain about non-intrusive, text-only ads. You can pretty much ignore them; I can usually just skip right through them, even if they're in the middle of a page. They don't really take up much bandwidth, and Google seems to be better at relevance than most people.

The real culprit here, in my opinion, is the evolution of advertising in the past few years. Starting with those pesky "Warning! Your computer is broadcasting an Internet IP Address!" ads, things spiraled downhill very quickly (Congratulations. You've just been selected to win two free Apple iButts). Then came the flashy, annoying, animated GIFs, which evolved into Flash advertisements, and then Slashdot had a post talking about Java advertisements. Seriously? Java? I should just uninstall it right now. I hate Java. If it's used for ads, I hate it even more. Obviously they're simply trying to get your attention, but really, this could be harmful for site traffic. My process of visiting a site with flashy advertisements is something like this:

1. Visit site, probably to read some article.
2. Start reading arti—why hello there, annoying advertisement with a flashing background that's enough to send a person into seizures.
3. Well, I can concentrate on reading, right? Here we g—what the hell.
4. Close tab/window.

If a website wants this kind of traffic, purely for generating revenue, they don't deserve to exist. Web administrators need to realize that to keep their content readable, they need ads that don't suck. Yeah, it probably means generating less revenue per view, but at least you stay relevant. Users don't feel like shooting themselves after visiting your site. Unfortunately, instead of being reasonable, I guess a handful of webmasters decided to "ban Firefox" instead. Yeah, right. Ban Firefox? What a joke. The only point you're making is that you're a jerkoff, being completely inconsiderate of people who use Firefox without an ad blocker. Apparently we're just a statistic, and since they're losing so much money, they figured it's just best to kill us all.

So now we've traced the blame from the ad blockers, to the ad-laden website owners. Of course, it doesn't stop there. What's with the ad companies producing these wacked up ads that they must know just annoy the crap out of everyone? Yeah, they're trying to get our attention, but in what feels like the worst ways possible. Unfortunately, even Google seems to be moving in the direction of video ads. Sounds totally evil, but I can only hope their implementation is better than it sounds. If not, I'll just have to quit the Internet.

But these crazy ads must work on some people—obviously not tech nerds like us, but believe it or not, "less intelligent" people do exist! Or maybe it isn't that they're dumb. Maybe they're just heavily invested into materialism.

If you've never read Feed (Slashdot review), I highly recommend it. I read this for ENGL106, and it's probably the one thing I really enjoyed doing in that class (thanks to Jennifer Eason for having us read it). Essentially, to copy Wikipedian vocabulary, it's a dystopian novel about corporations, consumerism, and computer technology. It's kind of scary how it seems like advertising is heading in that direction. The premise behind the novel is basically that ads become completely integrated with people's lives. People get flooded with ads whenever they go places. I don't want to spoil it too much, but if you have no intention of ever reading the book, the Wikipedia article seems to do a decent summary. You think ads are bad now? I bet it'll only get worse.

Pythonic programming and the "self" keyword

Bruce Eckel recently posted an article which expressed seeming disappointment in the direction Python 3000 was heading. Particularly, he seemed to think the grandeur of a four digit version name was too much for what new things Python 3.0 will bring about. I can't really say that I care about some of his points (the GIL argument is one that's popped up on Reddit several times in the past few days), and obviously I only care to comment on one topic: the self keyword in Python. In his original post, he says the following:

This is something I really hoped to see in Python 3K, but the beloved self seems to be hanging on.

self is inappropriate noise in a language that lays claim to clarity and simplicity. No other mainstream OO language requires it everywhere like Python does, and it's a hurdle for people who try to come to Python from those languages. Maybe it's a significant reason that Java programmers seem to be more comfortable with Ruby; Ruby takes care of it for you just like C++ and Java do.

And posts later in a reply:

Exactly, and it's not the writing but the reading. Python generally makes code that's easier to read, but 'self' is an intrusion.

And parroting "explicit is better than implicit" is a misuse of that maxim. All languages provide abstractions; Python (generally) produces clear abstractions that tell you what's going on -- these abstractions are explicit in "the right places." But 'self' is something we don't need to see inside classes. You're in a class, so 'self' or 'this' can be implied, just as it is in every other OO language I know of. Ruby, I think, has it right on this one.

Some of you who have really long memories or have too much spare time on your hands would remember that I actually mentioned this topic in a blog post a long time ago. Obviously, with that mentioned, I disagree on both counts with Bruce's reasoning.

To begin with, I wonder just how much of a hurdle learning Python is because of a required self for referencing instance members. While they may not be required in other languages, they most certainly exist, usually in the form of this rather than self. Is requiring self really a hurdle? In terms of using it inside method bodies, I don't think it's a very big deal. Specifying that a variable belongs to an object makes it more clear as to what's going on, especially in a dynamic language where variable declarations don't exist. Even Ruby, as mentioned in the thread, uses @ as a scope resolution operator.

Bruce also argues that the "explicit is better than implicit" maxim is wrongly cited as a reason here, claiming that implicitness improves readability. I definitely don't agree here, either. In C++, Java, and C# (and probably more?), classes are well defined with what members they have, so implicitness works fine. In Python, since you don't really have instance variable declarations, being implicit seems like a bad idea. If you're maintaining someone else's code, you'd have to make sure all of your local variables weren't actually instance variables, lest ye overwrite them and screw something up. GvR's response also indicates a technical challenge in removing the required self.

Brandon Corfman also responded, saying:

The problem is that the 'self' plague doesn't stop there ... don't forget that self is required as the first parameter of every class method. For example, the following code that forgets to use self as the first parameter of printInfo:

class MyClass(object):
    def printInfo(s):
        print s
   
def main():
    m = MyClass()
    m.printInfo('Hello')

When running main, you get the following traceback from Python:

Traceback (most recent call last):
  File "", line 1, in 
  File "hello.py", line 7, in main
    m.printString('Hello')
TypeError: printString() takes exactly 1 argument (2 given)

Except I am giving one argument! What second one is it talking about? Oh yes, the interpreter is expecting 'self'. Totally confusing and brain-dead requirement. Why does this need to be the first parameter of every class method?

I think explicitly using self as the first argument is a good idea, to some extent. It's kind of quirky (I'm pretty sure you can name it whatever you want, and it would still work), but having self be in the parameter list shows C programmers (and other, maybe more inexperienced OO programmers) how instance methods basically work. They aren't some voodoo magic higgity biggity, they really just pass the object as an invisible first argument to the method. In the above case, m.printInfo() is really just shorthand for MyClass.printInfo(m). Python's explicit requirement of self as the first argument makes it so that it's clear to people what the difference between instance and static methods are (even though they're different in Python than Java, et al). The exception message is still kind of confusing until they make the revelation of that m is basically the first argument, but this concept is probably something most programmers who deal with OO should know.

The Scheming senior

Life has been busy once more, since school started. For some reason, I thought it would be a good idea to take three CS classes (software engineering, programming languages, and cryptography) as well as music theory. Music theory appears to have homework due every class, which sucks, even though it's pretty easy so far. In addition, being a senior now, I have to start worrying about what direction I want my life to go in next year. Of course, being me, I'm still rather indecisive over graduate school versus industry.

Research, to be honest, is so far basically what I made it out to be—boring. It didn't help that I picked a topic that I wasn't particularly interested in, but I'm doing my best to stay interested. Professor Mathur seems to be very passionate about what he does, which helps my motivation a bit. Even though it's not that exciting (calling it flat out boring is also an exaggeration), I guess this is a good experience for me to actually have a mentor that's been in the field for years. Hopefully I can get the motivation to finish this research project and publish a paper at the end of the semester, which would look nice on a resume for grad school. Weekly meetings should boost my motivation, at least a little bit.

Classes are kind of "meh" right now. Software engineering is definitely a lot less exciting than I thought it would be, and kind of wish I had taken something else instead. The project is some sort of grunt work from HP that has to do with finance. It definitely sucks compared to the project binder that we saw, which was a game of some sorts. From what the programming languages book is saying, the class will get more interesting as time goes on, but the current chapters are boring. Cryptography is pretty interesting; it's probably the most interesting thing right now. Music theory hasn't gotten past playing scales, so it's not very exciting. Playing on the keyboards on Friday is kind of fun despite the simplicity, since I haven't played piano in about seven years now.

Perhaps the most interesting thing that has happened lately (at least to me) is the arrival of my latest shipment from Amazon, consisting of:

• The Little Schemer, 4th ed.
• Serenity, Collectors Edition
• The Design of Sites

The Design of Sites is more to get some inspiration for web design, since I clearly suck at it. I guess this is necessary, since the web is the wave of the future. Or whatever. It seems to be very illustrated, but I haven't really looked too carefully at it, yet.

Serenity came out recently, which I couldn't resist buying, even though I already own the original edition. Firefly is one of my favorite series, and extended scenes and more bonus features makes an already awesome science fiction universe even more legen—wait for it—

Last, but certainly not least, I've already gone through two chapters of The Little Schemer. The book takes on a very peculiar format, based purely (at least so far) in Q&A format. They ask questions that you can hopefully answer and give explanations for each answer. For a fairly advanced programmer like me, this is amusing at first, but tiring in some spots. I was hoping for a book that I could read cover to cover, but this doesn't seem to be the book. Not that I'm disappointed with it at all, I just don't feel like reading through levels of recursion that are obvious to me.

This brings about an interesting pedagogical method; Friedman and Felleisen take an approach that depends on the human ability to recognize patterns. It seems like if you ask enough questions, the reader should be able to figure out what a certain function does. I had kind of an advantage of already knowing what some of them did, so playing a game of 20 questions was a bit overkill, but I wonder how this teaching method would apply to a more inexperienced student.

Actually, I already use this method somewhat with students. Whenever a student asks me a question that I deem should be obvious or already known from previous labs/lectures, I bombard them with questions until they figure it out. Unfortunately, this doesn't always work, possible due to a few reasons:

• The student is lazy. This might be a mean thing to say, but I think it's true. Graduate TAs that run consulting hours complain about students being unable to debug on their own, which I believe should be fairly intuitive. I've even had someone cry, possibly to get me to write the project instead.
• The student doesn't really understand the language. Compared the Scheme, Java is pretty complex, and some students never really properly learn some language constructs (e.g. the static keyword). This presents a huge problem when you get errors like, "non-static variable referenced in a static context." This is more of a lack of knowledge than reasoning ability, so this is where I throw my hands in the air and tell them to read the textbook.
• I'm not asking enough questions or I'm asking the wrong questions. This is quite possible; unlike the concepts presented so far in this book, so it's not always possible to ask an exhaustive list of questions to make the student reason through exactly what mess he/she has just made.

Regardless of the potential for failure, I think this could be applied to some specific topics for students to look like. The static keyword is probably a good target to start with. It is not as difficult to make an exhaustive list of questions for the students to "pattern match" through for one single concept, but I guess it's too late to use this kind of method when they're working on projects midway through the semester. Hopefully I can get some spare time to concoct an article for using the static keyword, and get some response from students on how beneficial it was.

Anyway, this has been a very random grouping of topics and I think I've poured out my heart and soul enough for tonight.

Dary.

The not-as-exciting Austin post

Not to insult Austin or anything, but I'm lazy, and most of the work was done for me already. James posted a fairly comprehensive summary of what went down in Austin.

The only thing I have to mention is that I'm noticing a trend when comparing Purdue's campus to others (such as MIT and UTA). I wonder if it's really just because I've seen Purdue for three years.

The super-exciting Boston post

Yeah, so this post took about 5 days more than it should have. Oh well.

All was quiet from my end of the Internet this past weekend, since I was at MIT visiting my so-very-dear friend, Julia. Of course, like the rest of this year, my airport experience was highly unpleasant at best. I decided to fly US Airways since it was cheap; apparently they were cheap enough that they canceled my flight out on Friday evening without citing a reason, forcing me to fly out at 6:20am on Saturday to be able to spend any significant amount of time in Boston. My flights were delayed a little bit anyway, and filled with crying babies, further adding to the flight fun.

After arriving in Boston, we went to a Vietnamese restaurant around Harvard where I had phở for the first time, along with some sort of beverage made of jackfruit. Phở is basically a beef noodle soup, though there were some ingredients within that I couldn't identify (and thinking back, would probably rather not); it was pretty good, especially since I hadn't had breakfast, despite being awake since 4am.

After lunch, it was pouring extremely hard, so we spent rest of the remainder of the day in the comfort of a dorm room. The dorm is a graduate dorm, and it provides a better environment than any dorm at Purdue ever has (or will); the dorm is replete with computing facilities, conference rooms, as well as apartment-like suites that include kitchens as well as bathrooms, never mind the fact that each room was bigger than a shared double in Hillenbrand. For dinner, I stood by idly and watched Julia cook we cooked chicken parmigiana, and since I'm alive, clearly it wasn't toxic. Too toxic, anyway.

After waking up at noon on Sunday, we had pancakes, eggs, and sausage (read: fat) for...for lunch, I guess. We took a mini-tour around MIT's campus, which was interesting; it's pretty different from Purdue's campus, which I would call boring at best (and smelly during select seasons). To begin, Purdue's campus is fairly confined to a smaller area, unlike MIT (and IU, for that matter); smaller areas aren't very exciting, but I guess it's nicer for walking to class. MIT's campus is a little more widespread and more "scenic," being that it doesn't reside in a town as tiny as West Lafayette. MIT also has some fairly interesting architecture, such as their CS building, which is probably the wackiest building I've ever seen in my life (photo shown below; not mine). More to the point, most of Purdue's buildings are pretty boring (new CS building, anyone?); maybe the architecture is just a novelty that would wear off on me if I saw it every day for four years, though.

MIT seems to have a more interesting history than Purdue does, as well. Maybe it's because of MIT's incredible nerdism that makes them measure bridges in terms of people, but as far as I know, Purdue feels pretty bland in comparison. Not that we don't have our own share of of urban legend to spice up our history, but it seems like our student population is confined typical college activities of partying and tipping cows studying hard. Of course, it's also quite likely that I'm left out of the loop, since I never leave my room.

MIT hacks are also a very interesting part of MIT culture. Putting fire trucks on top of buildings and putting blown up versions of a class ring on a stolen cannon seem to be above things that Purdue students (or administrators) could ever manage. Of course, I'm not exactly an expert of Purdue culture either, so I can't really make too many comparisons, but I think it's safe to say that Purdue is relatively normal; after all, we appear to be a relatively conservative campus.

Of course MIT has its downsides too, such as living through X years of torture, paying more money for one year than I pay for four years at Purdue, and so on. Paying so much more might entitle you to better living quarters among other things (being around generally smarter people, getting a job automatically, you know), but the the painted picture of the academic workload seems...well, crazy.

We walked around Boston for awhile; the weather was much nicer than it is in West Lafayette now. Even though it was overcast, it wasn't raining, and there was a nice breeze to keep the temperature nice. In West Lafayette, it's blistering hot, and I start sweating just walking back to my apartment from work. Lucky for me, I'm not playing tennis anymore, unlike two members of my family, or I'd probably be dead by now. Anyway, Boston was a pretty nice area; I certainly like it much more than I liked New York City when we visited for spring break (possibly because it was snowing and very wet). Boston didn't feel as congested as NYC always did (given that it was a Sunday), and I guess it just felt different (in a good sort of way?) walking around Boston; maybe I felt like I had a smaller chance of getting mugged.

It was kind of weird to see some university residences (MIT Greeks, BU dorms) sitting in the middle of a city, kind of like how Soochow University in Taiwan was right in the middle of a city. The buildings there were also unlike anything you'd ever see around Purdue, partly because some of them are very old compared to anything you would see in all of Indiana. I guess someone decided it would be fun to build housing vertically instead of horizontally to prevent people in Boston from getting fat; maybe I should move into one of those houses.

We ate at a Thai restaurant for dinner (I don't remember any names, I suppose I'm a bad tourist) and I had a yellow curry. I didn't realize they would just give you "extra" bowls of rice if you needed it, and there was an awful lot of curry sauce for just one bowl of rice, but it was still good. The rest of the night was spent watching South Park and failed attempts to get me to follow along with Japanese women doing aerobics and saying really odd things like, "I was robbed by two men" and, "take anything you want." I think their smiling faces indicated that they didn't know what they were saying.

We left for the airport basically right after waking up. My flight back was also delayed at each leg, and I ended up getting back home about two hours later than I should have. I don't know if I just pick terrible times to fly or what, since I don't think I've ever encountered this kind of luck before. At least I wasn't flying Northwest, who appears to be canceling flights like nobody's business, or I'd probably still be in Boston. Alone.

So all of this took way too long to think up and write, and I leave for Austin in a few days to visit James, a lazy bum who hasn't posted on his blog in awhile, all the while thinking he can bug me about my blogging!

CS180: Debugging

One major point that CS180 seems to be lacking teaching students about debugging--understandably so, because it seems like debugging should be a fairly intuitive process. However, when it comes down to programming projects, plenty of students come in to get help with the same situation: They've programmed their entire project, but it doesn't work. The degree to which their programming is hopeless varies by student, but in general, consulting TAs can get exasperated with bad programming practices and helplessness in regard to fixing bugs, be it at runtime or compile time.

One hopefully helpful way to attack this problem will be to have a lab about debugging, which will be fairly early in the semester. What I'm interested in hearing is what people think should be included in a lab like this. Since the lab is planned to be early on, it's difficult to have students attack complex scenarios and fix bugs in them. Perhaps the only thing we can teach them is the "development cycle," which seems to be: edit -> compile -> fix compiler errors -> compile -> run -> fix runtime bugs -> etc. This is pretty natural to students, and I haven't really seen any students who didn't understand that cycle. The problem really lies in the fact that they have no idea how to fix either type of bug.

In most cases, Java tends to spit out fairly reasonable error messages, which means students should be able to figure them out. Do they even bother to read them before calling a TA over? Sometimes I don't think they do--perhaps it would be in our best interest to have them sit on it for awhile, first. I seriously doubt it's difficult to understand what "missing semicolon" means. Another thing that needs to be pointed out is that compile time errors need to be fixed from the top, not bottom. Since one error (particularly syntax errors) can cause an explosion of false alarms, fixing from the bottom is often unhelpful and incorrect. Even though a compiler may spit out 100 errors, that doesn't mean you have 100 errors to fix!

Teaching students to fix runtime errors is, in my opinion, an order of magnitude more difficult. Part of it lies in the fact that some students will have the wackiest implementations you'll ever see that really make no sense at all, but also somehow work--most of the time. JDB is a potentially helpful tool, but this probably isn't something we want to teach this early on (I think it sucks compared to GDB, anyhow). Other ways of finding errors would be via unit tests, print-and-seek methods, or main methods for testing. The first has not been taught in CS180 at all (or in any CS class, for that matter), so the second is usually what I tell students to do. However, they seem to be unable to insert their own prints in strategic location. This should probably be mentioned in the debugging lab, since it's the easiest to teach. Writing main methods that do testing for you is probably a good idea as well, but this isn't as applicable until students get into projects with multiple classes.

The more and more I talk about this topic, the more I see that there might not be a whole lot that could be put into a debugging lab, besides reading. If the lab is to be early on, then we can only teach them a small amount. However, maybe it would be good to write a series of articles on more "advanced" topics for later projects? Good programming habits aren't really taught in CS180 either, for who knows what reason. For example, programming in incremental stages and testing (at the very least, compiling) at each stage will help reduce the bug fixing stress students experience if they try to program all of a project before compiling. Another thing to point out is that having methods be fairly small/contained is a good idea. It could make finding runtime errors a bit easier, compared to having a main method that's hundreds of lines long.

I also thought that having some sort of debugging exercises later on via CS192 might be helpful, but I have no responsibility in that part of the course planning (and at this stage, I don't really plan to). For now, we'll have to assume that we have to teach them everything they need to know about debugging in one very early lab, and put the reset off for individual reading later. Along that note, someone (Ryan, perhaps) mentioned that having a centralized repository for this kind of documentation would be good--would we have any contributors if this were to be set up?

For the tl;dr (or those too confused by my post that should be edited, but won't be), answer these questions:

• What should be in a debugging lab?
• What shouldn't be in a debugging lab but is still well worth knowing?
• Are you willing to write about these things for a central repository?

CS180: Writing easy-to-grade labs

Maybe I'm having delusions of grandeur, but I think this should be possible. I'm currently envisioning a method of writing labs that allows a script to perform automatic grading (yes that's right, I've gone mad) for the ease of the lab TA. A little adjusting to how comments in the skeleton are done can go a long way. I'm kind of lazy, so I'll be using my super-trivial code example that I ranted about some time ago, with two TODOs added:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    /* END TODO 2 */
}

Usually the skeleton code will consist of a bunch of blanks you need to fill in, so if we specify and ending line for said blank, then you can tell what the student typed in for the TODO. This is a pretty simple approach, and allows you to swap out TODO implementations (say, a student's implementation for the solution's), which can be done by a grading script. This method would also take away the problem of TODOs that don't compile by default, which is an issue for students who can't finish their labs. You can test one TODO at a time, using the solution for the rest of the program.

Edit:This doesn't really take away the problem of TODOs that come non-compiling, since students can't test their program until it does. Duh. More on this later, maybe. Suggestions welcome.

Theoretically, this idea could be extended to make a script generate the skeleton code as well, since it seems trivial to extract the text between the comments and call it a skeleton:

public boolean foo() {
    boolean b = bar();
    if (b == true) {
        /* TODO 1:  Return true */
        return true;
        /* END TODO 1 */
    }
    /* TODO 2:  Write an else statement that returns false. */
    else {
        return false;
    }
    /* END TODO 2 */
}

I can imagine creating a directory structure for creating labs (kind of like Rails...except not):

solution/
doc/

From this, the lab spec would be written inside doc (how this will be done is yet to be decided), and the solution in the solution folder. Running a script after the solution is finished would:

1. Extract all of the solution text from the TODOs to create the skeleton in a skeleton folder
2. Create a tests/ directory that has a subdirectory for each TODO, where the author can insert Java programs to test that TODO
3. Generate the lab spec in HTML format in a www folder

This entire structure would be mailed out to all of the TAs, while the skeleton and www folders would be what was exposed to the students. When it came time for grading, you could have a generic script (I hope) that would take a test directory and a solution directory and run tests for each TODO on every student's files, generating text that would be mailed to students.

While automation would probably speed up grading by a lot, I still think there's room for grading things by hand. Emphasis on style, such as proper indentation, non-terrible horizontal whitespace) is much more difficult to automatically grade (if someone wants to write a script to do it, be my guest). Granting partial credit and giving advice for writing better code also has to be done manually, and I think it would be good if TAs at least spent time on this once every few labs (perhaps this should be designated; every third lab, maybe?). This process also doesn't help if we create write-from-scratch labs.

I think I've rambled enough for now; comments welcome, etc.

CS180: Writing and grading labs

Part of my summer goals for CS180 include improving the way labs in CS180 are done. There seemed to be a lack of standard in handling labs over the semesters that I taught, which actually weren't a huge deal, but I think it's a problem worth addressing. Different TAs tended to write their lab specs in different formats, which could sometimes be confusing; some TAs also wrote labs that were hard to grade, which ended up being annoying for all of the TAs. Specifically, the goals I have are:

• Write a spec writing guide (especially since I may be the only returning lab TA)
• Write a lab spec template and source file template
• Write a few labs based on the specs
• Write a lab "best practices" guideline (slightly unrelated)

In addition, a change that will be made this semester is that the last few labs (or at least some labs) will be written from scratch. A complaint I heard was that CS240's labs were hard to deal with, since many of them were written from scratch. This is a silly problem, and students should be learning how to build a program from the ground up.

Grading is also a worthy problem to address; there is no standard for TAs to grade by, which leads to a natural unfairness in the lab grades. I think expecting the lab author to also create a grading rubric is reasonable, and should help TAs grade more fairly and more quickly. If labs are able to be script-graded, I would expect the TA to write a script for it as well.

Another aspect of grading comes in how the student sees how he or she did, and what went wrong. Traditionally, when us old people took it, TAs would print out labs and hand them back; I tried this last semester, and it was a bit cumbersome to manage all of the paper (and wasteful, in my opinion). CS158/9 had its TAs mail students back with comments, which I thought was a better idea, but the way they had us do it kind of sucked.

For the TAs, I think the improvements for a major part seem to boil down to scripting. I imagine Python scripts could be handy for writing grading scripts, among other things. For one, the best way to generate a uniform HTML page for the lab spec is probably to parse some markup that generates the HTML for you, rather than force everyone to hand-edit a bunch of HTML. Or maybe I'm just deluded. Python could probably make a lot of things easier, but more on that later. Hopefully.

Comments on any of the possible changes are quite welcome, as I'm kind of rambling.

CS180: Editors and IDEs?

For some reason, we started using jEdit as our official editor in CS180, since apparently our students weren't hax0r enough to handle Vim or Emacs (we stopped using Eclipse as well, for some reason that I don't really know). Looking back over the past few years, I wonder if jEdit is such a good choice. They tout themselves as a "programmer's text editor," but I think it sucks. We have 25 [apparently theoretically] identical computers in the CS180 lab, but jEdit does wacky stuff like behave really oddly if num lock is on (or off, one or the other), not syntax highlight properly on some computers, etc.

I'm hoping that as the next head/lead/whatever TA, I can persuade the course administrators to change the editor, if I want, but I'm not entirely sure what I would suggest using. The options seem to be:

• Vim
• Emacs
• Pico/Nano
• Eclipse
• IntelliJ IDEA
• NetBeans

Some of these options are laughable (if you ask me, anyway). Using vim or emacs as a main editor is probably still not a great idea; it would be wise to learn in CS180 anyway, but the warring of the two editors means some students would be learning one and some would learn another, as mandated by the instructing TA. This is probably a crappy idea, and students should try both on their own, since the USB has tutorials on both. Pico on lore doesn't have syntax highlighting; I don't really know why we don't use Eclipse (other than I think it can eat poop), IDEA looks interesting (but weaning new programmers on IDEs means they're going to have tons of fun in CS240), and NetBeans? Yeah...

I'm open to opinions, though I wonder if anything will ever come of it. Maybe I'm just posting so I don't feel so lazy.

Interested in teaching CS180?

It's high time I started working on stuff I said I would be working on (progress report: completed 0%). Part of said stuff requires finding enough TAs for CS180 next year. Anyone interested in teaching little freshies Java? Leave a comment if you're interested--I know at least a few of you are TAs. I need three more at least, more to buffer schedule conflicts.

Interested in helping with CS180 but not so interested in teaching/grading? CS180 also needs evening consultants (4-6, maybe more), and I currently have none. Work is usually 3 hours per session. Check the now-outdated CS180 website for example schedule.

More to come about CS180 later, when I'm not lazy or at work.

Open source in the mainstream world

A Slashdot article was [somewhat] recently (it's summer, I'm lazy) posted referring to a Wired article (seems increasingly common nowadays), debating whether or not Firefox was becoming bloated due to more users using it and requesting more features (integrated RSS, all that fun stuff). Everyone's favorite browser (including mine, a Microsoft fanboy! *gasp*), becoming bloated?! No way!

This topic actually came up to some degree in the comments for one of my earlier posts (which apparently got two diggs, thanks to Dylan--but apparently I'm not cool or interesting enough). It seems like a lot of open source projects in the past have [over]emphasized modularity in their application architecture. The Firefox developers seem to be well aware of this, otherwise this article would have never appeared.

The Slashdot article accused Firefox of heading in the IE direction, i.e. (ha ha) bloated, like all Microsoft products are, according to some. That's a rather interesting accusation, considering Firefox is the jewel of open source. So why is Firefox heading in this direction?

Shamelessly citing my own comment, I was arguing that "extremely modular architectures" are not acceptable for non-technical users, and because of this, the most popular open source software would have to "bloat up" to really grab the attention of this population (which is who the open source crowd is targeting nowadays, right?). Interestingly, this implies that software bloat and "normal" customer satisfaction have an inverse correlation. I'm sure a large quantity of people, myself not withstanding, want their software to work, work well, and do everything they need--without having to install plugins!

Microsoft is constantly accused of developing bloated software, and that open source alternatives are so much better, because they aren't bloated. Can anyone really win this war? If more users equals more bloat, then there's a bit of a Catch-22 going on, especially for the "elite" users that complain about bloat in the first place. How can you satisfy more than one group of people? For example, a few comments on the Slashdot article pointed out that things like RSS integration are unnecessary to a browser and are really just bloat, and another complaining that excessive memory wasn't really limited to just Firefox.

This seems to be a pretty hard problem (perhaps NP hard? hurr), that I have no immediate solution to--it's more than just a programming problem, that's for sure.

Summer plans

Well, junior year has finally ended as of last Wednesday. Now I'm just crossing my fingers for good grades. Anyway, summer has rolled around and now it's time to "be productive." So what's going on this summer? In no particular order:

• Research. I've gotten involved with two professors over the summer, both somewhat tied to security. One of them is with CERIAS, where I think I'll be working with Bennett. The other is with Professor Mathur, which means it's related to software testing (for this project, also related to security).
• shaim. I started committing to shaim before school ended, and intend to continue doing so. For the 0.4 milestone, I'll be getting the event notifications plugin out, and for 0.5, I'll be working on getting IRC to work (making the third IRC client I've ever made).
• CS180 preparation. I have a few things in mind to change to hopefully make CS180 a better experience for the students and the TAs, which I might post about later. By the way, for Purdue readers, if you're interested in being a TA, let me know.
• Purdue CS Planet. A few of us came up with an idea of setting up something like a Planet except a bit more automated so it's low maintenance. No idea how far this idea will actually be taken, but I think it would be cool.

There's one more project that I won't mention for now, but between all of these, I think I'll be rather busy, but if I can manage my time well, I think this summer will ultimately be very productive.

Democracy and Digg.com

Digg recently had an incident, which is kind of still ongoing, in which someone posted (according to Wikipedia) "the full decryption code for HD-DVD" and got banned for it. In response, there's been tons of uprising/rebellion, with the key continually being reposted, etc. I've never been a very big Digg reader, but now I really have a reason not to read it. Why do Digg users feel entitled to post whatever the hell they want on the website, regardless of legality? That's plain ridiculous.

Some people have started marking today as "the death of Digg," and I sure hope it is. Not to be offensive to the creators, but if Digg ever does go away, I'm sure all of their whiny users will realize that they probably had more freedom there than on other websites, since it's much more community-driven, from what I understand, than Slashdot. If one of these rebels tries to start a Digg replacement that lets everyone post legally controversial content, I'm sure they'll enjoy the pleasure of having a lawsuit filed against them. Please, use common sense.

How to get the wrong people in your computer science program

A humoring thread came up on the Something Awful forums that I almost forgot about. The thread is about those schools you see that advertise on television ("Come to ITT Tech!!! Make some gamez!!!!!"); everyone who has seen those ads on TV probably deduces that they aren't very good at what they do (why else would they be advertising?). The University of Advancing Technology made a highly amusing blunder on their website:

Eating is a serious pastime at UAT. Lunchtime is never a quiet, reflective time for college students in general. But at UAT, it's a noisy, rollicking journey down the highway of fun. It's not uncommon to witness students engaged in vigorous Guitar Hero contests, or watching the latest anime on the big-screen. Or you can eavesdrop on impassioned conversations about the merits of C++ versus Linux.

Enough said, I think.

Monoculture in open source software

Slashdot recently posted a story linking to an article about the "why Microsoft wins the development war so often." The excerpt from the Slashdot article:

"Microsoft offers the certainty of no choices. Choice isn't always good, and the open source community sometimes offers far too many ways to skin the same cat, choices that are born more out of pride, ego, or stubbornness than a genuine need for two different paths. I won't point fingers, everyone knows examples... The reality is that there are good, practical reasons that drive people into the arms of the Redmond tool set, and we need to accept that as a fact and learn from it, rather than shake our fists and curse the darkness."

I'm wondering how true this is for other people. Joel Spolsky posted an article last year about choices being headaches (ironically talking about Microsoft!), but referring to GUI interface design, rather than choosing software in general. Even though Joel is referring to the quirky shutdown menu for Windows Vista, I'd like to think that it also applies to the context of the Slashdot article. I've noticed some projects fork off of others for no reason, or the ones listed above (pride, etc.); but regardless of the reason, it feels like the open source world has way too many paths to pick from. And to top it off, sometimes none of those paths are even worthwhile!

Don't get me wrong, the concept of open source software is good (even the software that's platform dependent on certain proprietary operating systems). I do think, though, that the whole "diversity" among existing software can be rather annoying. Quality software doesn't need to be forked (how many Firefox forks are out there, and who bothers to use them?). Maybe this is one reason why I'm still an avid Windows user; I have less decisions to make, and hurray for that.

AOL is in your chats, droppin' your packets

Since I started using Windows Vista awhile ago, the AIM 5.2 + DeadAIM combination stopped working. DeadAIM is no longer maintained, and registering my key doesn't actually work. I started using shaim in its place (just recently celebrating 1,000 revisions!), since I have a natural distaste for alien user interfaces, such as GTK on Windows (Gaim), Qt on Windows (Psi--not as related, I know), and whatever Trillian, AIM 6.0, and AIM Lite use. The reason I stuck with AIM 5.2 for so long was because it wasn't bloated, and it was simple; when AOL started adding in features from DeadAIM, I thought they made it look retarded, so I didn't upgrade.

In addition to using shaim, I also got commit access to the Subversion repository very recently, which makes this my first open source project. Unfortunately for all of you non-Windows users, shaim's UI is currently built on WPF, which means it's native to Windows. Now this is a good thing (OS X users, see: TextMate); however, even though it's currently Windows-native, it's built on C#, and Mono compatibility (for non-UI elements) is very feasible; the UI is modular, and can be rewritten using other toolkits/interfaces.

But now I'm getting off topic from what I actually want to mention; the UI rant can be saved for later. Recently, for our last OS project, I set up a Subversion repository to work with my roommate and left him instructions including the repository location, which was a file:// URI. The next day, he asked if I would be setting up a Subversion repository. What? I kindly informed him that he must have missed the message I sent him the night before, but he was fairly certain that he had read all of his messages. I sent him another one while he was in class, but apparently that didn't go through either.

I thought it might be a URL parsing error, since shaim previously had some problems with converting URIs to actual hyperlinks, but it turned out that such was not the case. I followed the logic all the way to watching Wireshark report the packet being sent out. Wireshark never reported the message coming back in! Apparently AOL servers filter messages that contain file:// hyperlinks. Try it yourself! Sending file:// in plain text works fine, but shaim automatically parsed all URIs to be hyperlinks. If you try sending "file://test" hyperlinked to yourself, you'll only see one copy of the message--it never echoes! This is because AOL's AIM servers simply drop any packets that have hyperlinked file:// URIs.

Is this really the best course of action? There isn't any sort of notification that the packet is dropped, which is really user unfriendly. AIM 6.0 doesn't automatically convert file:// URIs, but if you manually do it (for whatever reason), it still just drops. It feels like there should be better ways to handle these potentially malicious hyperlinks. For example, why not offload the processing to the client? The client could either reject (and send a notice! How novel!) the incoming message, or it could remove the <a href=... from the message. I'm guessing the AIM servers don't have the ability to handle that kind of processing load, but the clients could do it easily. This makes it plainly obvious to everyone (senders, receivers, developers) what's going on, rather than just dropping packets left and right and being so secretive about it.

The perfect programming language

This really can't end well, because there really is none that I've discovered thus far. I'm sure lots of people in any language's band camp would beg to differ, but whatever. This is clearly going to be a post based purely on opinion, because the definition of what a perfect programming language is, is incredibly subjective. Personally, I tend to put a lot of emphasis on aesthetics of a language. Don't get me wrong, features are obviously vital, but often times it boils down to how languages look compared to their cousins (there are times when I'll argue in the feature field, usually about Java and C#).

I'm not trying to put any specific language in the spotlight, but is it just me, or do imperative languages look nicer than functional languages? Having grown up on imperative languages, maybe I'm biased; I know there are people out there that prefer some icky, icky looking languages like Scheme as well, so maybe it all depends on how we're cultured. Awhile ago, after talking with a friend from IU, I decided I would finally stop being [as] lazy and pick out a functional language to dive into.

Now, being the person that I am, I like to analyze things to the point of death (read: complain) sometimes, so we spent the night looking at different languages on Wikipedia, after talking about how he didn't "get" imperative languages and I didn't "get" functional languages (even though he actually started on C++). We looked at languages such as Haskell, Lisp, ML, and OCaml before I decided that I thought functional languages were just ugly.

I have nothing really specific to complain about either; I think they all just look really alien or messy. What I'm really wondering is, do functional languages purposely try to look as foreign as possible compared to imperative languages? After picking OCaml as the language and going through some tutorials, I noticed a lot of concepts that were present in OCaml and various other imperative languages. It seems like OCaml just [mostly] removes mutability, allows you to pass in functions to functions (which allows currying, probably the coolest feature I've seen), and full type inference. Since OCaml is impure, unlike Haskell, it does allow mutability in records (structs), references, and arrays.

It seems like a lot of the examples that are given in the OCaml tutorials could be expressed similarly in C#; however, there are still [obviously] advantages of using OCaml for functional programming.

• OCaml is optimized as a functional language. For example, the CLR has a sub-optimal performance on performing its .tail MSIL (now apparently called CIL) instruction. A developer for Nemerle commented on writing manual tail call optimizations, which eliminated the use of .tail by using a simple jump instruction, but pointed out that mutually recursive methods are still not optimized.
• Currying on C#, while it can work, doesn't work very well. You have to create your own classes for generating lambdas via anonymous delegates. The main article shows a type unsafe way to do it, as pointed out in comments; in order to provide type safety, you would have to add a type parameter for each argument to the Curry method, which could get cumbersome (e.g. Curry<K1, T1>, Curry<K1, T1, T2>, etc. where K1 is the return type and T1 are argument types).

On the other hand, I think C# in the general case brings a lot more to the table, concerning syntax (aside from full type inference, though it seems that C# 3.0 is moving towards type inference). I definitely like the C-family syntax a lot more (inherited bias); it feels terser than the ML-family syntax. I also think it's kind of silly how OCaml uses a semi-colon to separate statements, with double semi-colons to end blocks. Using braces feels more sensible to me, or at least something to enclose a block.

Along the same lines, I've never been a big fan of optional parentheses when it comes to calling functions, either. I first encountered this when learning Ruby and thought, "Cool!" However, after awhile, I changed my mind. It feels like optional parentheses are just for lazy people, and doesn't really increase readability; rather, it encourages laziness where applicable (I guess the space bar is a lot easier to hit than the parentheses' keys). I've never really gotten why Lisp and Scheme put their parentheses on before the function name, either. Of course, I know absolutely nothing about the Lisp family, so I'm sure there's a reason, and I'll get around to learning it. But really, what's so bad about "fun(arg1, arg2, arg3)"? In high school and onward, we're taught that functions are represented exactly like that, so I would think that using that representation would make more sense.

So why can't a language like C# take on the cooler features that are present in OCaml? Here's a [small] list:

• Type inference - I know C# 3.0 is working towards type inference, as mentioned above; I don't think it will ever reach the point of full type inference, like OCaml. I had the opportunity to sit in on some language design meetings (and didn't understand much of it), but from what I understand, OCaml accomplishes full type inference by having literally no implicit casting at all, including promotion of numeric data types.
• Currying - Maybe I think this is just really, really cool; I haven't programmed anything major in OCaml, so I don't know just how valuable currying is (the examples provide some interesting uses, but they're just that--examples). By looking at Sriram's article, it seems like it would be possible to have the currying functions that he wrote generated on the fly, rather than forcing the user to write it all.
• Support for more optimal tail recursion - From what I understand, recursion and tail recursion are used very often in functional programming languages. Thus, providing a better optimization for tail recursion would get some imperative programmers thinking more functionally.

Interestingly, the comment about Nemerle brought me to their website. In their own words:

Nemerle is a high-level statically-typed programming language for the .NET platform. It offers functional, object-oriented and imperative features. It has a simple C#-like syntax and a powerful meta-programming system.

It sounds a lot like what I'm looking for, but I wonder if I'll actually like it. I'll put it on my list of languages to learn/look into; I'm still going to finish going through OCaml tutorials, at least. Unfortunately, there won't be much of that until school is out.

Java as a first programming language

A thread on the Something Awful forums came up recently about a high school, second-year computer science/programming course. The author was requesting help to convince his teacher to switch said course from using VB6 to C#. There were a number of suggestions and alternatives given (Java, VB.NET, Python, Scheme), but that's not as relevant to the CS environment at Purdue (thread is here if interested). I got into a couple of discussions about C# and Java, and it brings me back again to imagine what Purdue would be like if we didn't teach Java as a first programming language.

The issue I brought up was an argument against teaching students how to write procedural code in a purely object oriented language. In particular, someone suggested that teaching procedural code in C# was easy, since you could simply add the static keyword to class methods to write non-object oriented code. I argued that teaching the static keyword before telling students what it meant was a particularly bad idea. I've never been a fan of teaching stuff out of order (who is?), but it seems impossible to teach things in order in Java. This is plainly visible by Java's hello world program:

class Main {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

This is incredibly ugly, and C# is guilty of the exact same thing. For beginners, I don't think this is acceptable. Unfortunately, all compiled languages that I know of are guilty of this to some degree; on the other hand, scripting languages can do hello world programs in one line. When you introduce this Java program to a student, here is what new programmers tend to think:

1. What is public?
2. What is static?
3. What is "main"?

The list can continue (what is System, out, println, etc.), but the point is, there are a lot of questions to be answered that can't be answered without covering material that they aren't ready for. In particular, I believe the static keyword is a real killer, even for some people who've programmed before (obviously not in depth). Instead of reiterating everything I said in the thread, I'll just copy and paste like the resourceful (read: lazy) person I am:

I think the static keyword versus other language syntax is slightly different. Why should you have to teach the static keyword first in an object-oriented language? In terms of thinking about objects, static "breaks" the OOP paradigm. One of the C# compiler devs even argues that the static keyword shouldn't exist. Obviously you need some way to differentiate between instance and static methods, but I never really liked to use of the word "static" to do so. Maybe it's just me, but when I hear the word in a general context, I take it to either be in terms of static you see in TVs, or static as in unchanging, the latter of which is due to static/DHCP IPs. Are people really supposed to be able to tell what "static" means, just offhand?

OOP languages like C# and Java are actually backwards in terms of expressing methods and their arguments. If you were to write OOP code in C, the "instance" methods would be the ones with the extra typing (the first parameter being the object type), and the static methods would simply do the opposite. In Python, declaring methods is the exact same way. All instance methods in Python begin with a "self" whereas static methods simply don't have a self. You can also call instance methods with static syntax, which gives some insight into just how OOP methods are actually defined.

As far as learning is concerned, I think Python is better for teaching the difference between static/instance methods (other topics are debatable). I really don't like telling my students, "oh, don't worry about this huge, gigantic header you have to write for your main method--or what a main method actually is. You'll learn that later!" {}, (), [], and <> are introduced in a more appropriate order (though funny enough, I do have students that still don't get the paren), so I don't think it's [as] relevant.

A post from another user probably summarizes very well:

introducing students to computer science through languages which introduce syntax issues long before they introduce computer science concepts is a recipe for failure, and I completely agree. Aside from the utter boneheadedness of an "objects early" or "objects first" approach, you're giving students a gigantic chunk of boilerplate code and not explaining what any of it does. Seriously, just think about it: a student is not going to be thinking in object-oriented terms right off the bat, so how do you explain what this "public class" and "public static void main" business is? The Javaschool answer is "we don't, we just tell them that it's not important and they'll understand it later." This is not an acceptable approach.

From what I've observed, Java is taught at Purdue (and other schools) for a few reasons:

• Java is the number one language used, at the moment
• Java is heavily involved in other courses (for Purdue, often data structures and compilers), and not teaching Java would have a severe impact on the curriculum
• It's a good gateway to other statically typed languages, unlike Python and company, because of syntax similarities

There was, however, a comment by the same user above, regarding Java in computer science programs:

I've been doing a lot of research into computer science education recently (I'm more or less rewriting a computer science curriculum for my college), and there have been numerous studies which show poor computer science retention rates in Java-based computer science programs (equivalent to ACM CS1 core) that have improved substantially when the course syllabus was switched to a simpler language like Python or Scheme which allows students to focus on computer science concepts rather than fighting with language syntax. Pummel them with Java later.

While the idea of teaching a language that isn't statically typed bugs me, maybe it's just my upbringing in C. As far as static methods in classes go, I would certainly agree that Python does a better job of getting the idea across, as said in my quote above. However, I also think Python offers a lot of freedoms that aren't available in C# and Java (as do most scripting languages), which might increase the difficulty of learning statically typed OOP; nevermind the syntax differences between Python and "C-family" languages.

On the other hand, Python's enforced proper block indentation also brings something refreshing to the table. I've seen some extremely bad indention in Java (literally different levels on each line in a block!), and I think Python has taken a good step by enforcing uniform indentation. Unfortunately, we don't see this in most languages, so this is a nice plus to using Python as a learning language.

Unfortunately, I'm still not sure teaching Python as a first language is a good idea. I sure don't like Java (for anything), but then again, I don't know of any languages that I would rather teach students that have advantages that are substantial enough to merit a change in a class syllabus. I don't think functional languages will ever fly here, regardless of how pretty or ugly they look; the idea of CS180 is to prepare students for CS240, which transitions from Java to C. I don't think the Pythonic way of doing things will prepare students for C; it may teach you how to program, but as much as it makes no sense, I'm guessing it would just pass along the problem to the CS240 instructors. And we all know what kind of monster that would awaken.

Apparently computer science at Purdue sucks (Part 2)

Here's a response to several posts (linked) about Purdue CS from "I'm a 10!":

Non-CS CS students

I'm sure the statistics agree that the percentage of students that enter without any computer science background and stay is much lower than the percentage of students that enter with prior experience. I would also argue, however, that part of it is because those students enter CS without knowing what they really want. I've used this argument a lot, and it might not be true [anymore], but I think a lot of students come into our department because they think they're good with computers; this is patently incorrect reasoning. I think for people interested in CS, they should try to get into programming before they leave high school to see if it's really for them. Of course, sometimes it's formally impossible to do so.

While I'm one of the fortunate that had AP Computer Science offered at their high school, not everyone does. One of our CS180 lab instructors came to Purdue with no formal experience, because his school didn't offer it. This is a commonly cited reason for not having experience, but I don't think I buy this as an excuse. In most situations, I find it hard to believe that a high school student doesn't have the time for some self-teaching; I also believe that if a student is unable to teach him or herself, it might be a sign; after all, software engineering is hard. This is not to say that it's impossible, or that people with no experience entering CS at Purdue will fail, as a counter-example is provided above, but I don't think it's making it easier on anyone. To me, computer science is one of the few areas where you can get some real, practical knowledge before entering college. I'm fairly ignorant about other fields, so it could be one of many.

Of course, to shift all of the blame onto the students is probably biased elitism. I think the curriculum could use an overhaul, but such a task is time-consuming, bureaucratic, and not likely to happen. There are a lot of issues at hand, and I daresay that it's impossible to solve them all. Primarily, not all professors that teach classes want to be there. From what I understand, all professors are supposed to teach at least one class a semester, but not all professors are interested in teaching, much less teaching undergrads. The same goes for TAs; I've heard of a number of graduate TAs that don't seem to put much effort into their teaching, or their knowledge of the subject is restricted to an inapplicable domain, or some other random problem. Is it impossible to find grad students that care and actually know something? I don't think so. I've come across several good TAs over the years; perhaps they're just a minority. In all reality, this applies to undergrad TAs as well. I've seen some TAs who either don't care, don't actually know enough to be very good TAs, or just think that students that ask questions are dumb. Since I think I'm taking over as lab admin next semester, I sure hope I get a say in who will be on my lab staff.

Course syllabi also vary significantly from professor to professor. While I understand that professors have different teaching styles, I don't think it's a very good idea to have such a significant difference. For example, I took CS251, our data structures class, in the fall, which is off-semester. The class was a piece of cake and I hardly had to study for it. The kids who took it in the spring had incredible amounts of work, including building a web server using certain data structures, etc. While I think it's cool to work on practical projects like that, I think it's unfair to the students who have to do significantly more work for less return. The objective of the course should be learning about data structures, their run times, and how to implement them. All of the extra stuff is nice for the very advanced students, but adds incredible stress to everyone else.

Administration

I can't really comment much on this, since I'm not in the USB and have zero interaction with higher administration, but I'm guessing it's related to my statements above, since the higher administration are a subset of the faculty. I have no idea what caused a strained relationship between the administration and the USB, but I really fail to see why bygones can't be bygones. It seems that both the students and the faculty know what's best for the students, which just causes a deadlock in improving our CS curriculum.

The new building

To some degree, I agree that the new building has had a negative impact on the little sociality that our CS department had. I think the lack of a new undergrad lounge is kind moot point, since it's [kind of] migrated to the small area outside of the advisors' offices as well as the computer labs, where a lot of people seem to do work. I'm pretty sure the administration knew that the commons wouldn't be occupied by many CS majors, but I guess they didn't have much else to do with that space besides make it look pretty. Besides, the commons brings girls into our building, what can be so bad about that?!

My real issue with the new building is the bureaucracy that's been added to the advisors' offices. There's a secretary outside of that block now, and we have to sign in and out and set up appointments to meet our advisors; I would label this as being very close to the pinnacle of ridiculous. I don't think the advisors have ever had any trouble doing all of the work they needed with an open-door policy (which closes when stress levels rise), so who thought it would be a good idea to formalize social interaction with our advisors? I used to visit my advisor very frequently, and now it's reduced to one visit every few months; usually it's just to schedule my next semester. This sort of alienation between the students and the advisors is the last thing the department needs.

Apathy and entitlement

Apathy, as partly mentioned above, is a big kicker for the students and faculty. The faculty might not care, but the students often don't have more motivation than to complain on a newsgroup or to their own peers. The CS feedback panel hosted by the USB on a yearly basis shows little attendance from students that have issues with the way things are done, and sometimes the ones that do show up have very little constructive feedback to give. Even if there was a larger attendance and more feedback, does the faculty even care? Does anyone read their course feedback? I've read mine from teaching a CS158 (C for engineers) lab as well as for MA366 (ODE), but I've never really seen any active caring in CS180 about what sort of feedback TAs get. Is it like this for all classes/professors? No, but probably a majority.

My own conclusions

Despite all of this prose that looks like a bucket full of complaining, I'm actually not as dissatisified with CS as I seem. I've passed all of my classes and have started learning new stuff lately, which is good. Education and how to better teach in a CS180 lab are specific areas that I'm interested in, as a TA. I feel like it's my duty to try and reduce the number of people that drop out of CS because of CS180, but what's the use if they just drop out when they get to CS240?

I've jumped to conclusions before, but I wonder if other universities have these problems. It seems like a university with a CS department that genuinely cares about its undergrads would be a utopian department. Unfortunately, I don't think these universities exist.