Quote from an email I received from a prospective PhD student:
I get the impression that if doing a PhD is really going to help push me forward on this, I’ll have to be working closely with people from that whole milieu surrounding the ’80s/’90s Common Lisp scene and the heyday of PARC. There seem to be not too many still around who are still doing work along the same lines and who could serve as thesis advisors. I joke with my friends that it’s like trying to train under an old Jedi master – you’ve got to find their hideout in the swamps of Dagobah.
Sit down, younglings. Let me tell you the story of the Jedi Masters.(*)
A Long Time Ago in a Galaxy Far, Far Away…
This is a post about CS education. It is prompted by a series of posts by Mark Guzdial in which he criticizes the pervasive belief among CS educators that when it comes to programming, there’s not much an instructor can do: some students get it, others don’t; it’s all in genetics or other external factors that CS educators can’t influence (aka the Geek Gene Hypothesis). I am with Mark on this, but I feel a bit stronger about it than he does. I think that attitude is bullshit, and the studies supporting it are unsound by means of making conjectures ignoring an enormous number of confounding factors.
Throughout history, and even today in certain parts of the world, attitudes like this have been the basis for keeping entire segments of the population uneducated (“teaching women to read and write?! seriously, they can’t do it, look how much longer it takes for them to learn” or “blacks in Universities?! seriously, they can’t do it, look how their grades are so much lower”). This is basically the attitude of a class of educators who live so much inside the box of convention and intellectual lazyness that they are uncapable of seeing the big picture. I know this, because of two things. First, after the first few years of being a professor, my conclusion was the same: there’s nothing I can do, some students get it others don’t. I’ve learned a few things since then, and I know I was completely wrong. I was being a “Null Professor” at the time. Now I know better. Second, looking back at my own experience as a college student I was one of those students who “didn’t get it” at first. In fact, I had no idea what I wanted to do when I grew up, and in my Electrical and Computer Engineering program, programming was one of many topics that came my way; understanding and learning to love programming was a slow process that came only in my 3rd year of college.
Let me expand on these two points. Continue reading
I just came back from a week at Hacker School in New York — they invited me to join them as a resident. I thoroughly enjoyed the experience and, before I forget, here are my impressions and a bit of a comparison with the more traditional educational programs that I’m used to.
I have been meaning to put a few of the chapters of my book here. The Code Golf Style is one of my favorites; fun too, and a crowd pleaser! I’ll start with it. Here is the complete Code Golf chapter.
Before I do that, here is the post I wrote some time ago explaining what the book is about; you may want to read it. TL;DR: 33 different styles of writing a term-frequency program — count words in a text file, excluding stop words, print the 25 most-frequently occurring words in decreasing order. The emphasis of the book is on the constraints behind each style, as the task itself is trivial on purpose. All the code is in github. In my courses, my students go through these exercises one by one, rewriting them in their favorite programming language. It’s… a challenge!
Back in September, I blogged about one of the the most amazing conference experiences I ever had, the OpenSimulator Community Conference (OSCC’13). This was a 2-day, purely virtual conference with a total of 360 attendees, held on an OpenSimulator virtual environment hosted here on one of my super-duper servers. I’m one of the core developers of OpenSimulator; I do it partly to keep my work in software research real [by means of being in the trenches of a complex server with a relatively large user community] and partly because I love to use virtual reality environments, and use my vLab on a daily basis.
This post explains some of the optimizations that I made to OpenSimulator last summer so that it could actually support this event. This is the summary of a paper that will be presented at the Summer Simulation Conference, joint work with my student Eugenia. The preprint, pre-revision, version of the paper is available here.
(The work described in the paper and this post focuses on only one of many improvements that were made last summer by several developers.)
I’m happy to announce that my book Exercises in Programming Style is now available for pre-order from Amazon, and that it will be shipping starting June 9! This is the book behind the talks I gave last year at StrangeLoop and GOTO. This is the story of how this book came to life, the inspirations behind it, and what the book is trying to do that is different from the hundreds of textbooks about programming.
I’m officially making up these new words, because they correspond to activities that I do on a regular basis and that I need to convey to my students. I hope that by giving these concepts their very own words, they will lose the threatening overtone that these remarks usually come with — because students will realize that these are all very common problems indeed!
One of the most brutal things to adapt in life after college is the sheer amount of feedback, criticism and rejection that come with real life. This happens in just about any direction one decides to go: graduate school, industry, public service or self-employment. It may not feel that way for students, but school is an overly protective environment; getting a C or even an F may seem like the end of the world at the time, but that’s nothing compared to doing the best we can in a project/job, giving it all we have, just to hear from someone we respect that what we’re doing is not good enough. I’ll talk about Academia because that’s what I know best, but these observations apply in general.
This post was prompted by a Facebook interaction regarding Dijktra’s famous “GO TO Statement Considered Harmful” article, a letter he sent to the editor of CACM back in 1968. Seen through the lens of currently accepted research reporting practices, Dijsktra’s article reads like a technical rant, something that we might find in today’s blogs, but that have been essentially abolished from peer-reviewed research publications. Here’s a person stating his strong opinion about a language construct that he dislikes, starting with a strong premise about the negative effects of that construct without presenting any data whatsoever supporting that premise! As far as anyone can tell, the premise was based entirely in his own experience and intuition — which happened to go against opinions of other famous Computer Scientists at the time like Knuth. Granted, this was just a letter to the editor, not a full-blown technical article. However, the influence of this letter is unquestionable! Following Dijsktra’s rage against GO TOs, practically all programming languages that came after it avoided that construct, and the ones that didn’t, work hard at hiding it from programmers, sort of like “oops! sorry! there’s goto, but try to avoid it, ok?” (Also, this letter was single-handedly responsible for starting the meme “X considered harmful” that has been going on in CS since then, although credit for that meme goes, not to Dijkstra, but to the CACM editor, who spiced the title a little bit from its original “A case against the GO TO statement.”)
Whether GO TO is harmful or not, is besides the point. In the process of writing my upcoming book, I spent a considerable amount of time over the past year looking through old CS literature. It’s fascinating! The topic of this post is the evolution of methods in Computer Science research for the past 60 years, and the changing ways by which ideas are considered well-argued for.