This post comes from an email conversation going on related to programming languages vs. libraries. The story goes that these days, the major productivity gains come not from new languages but from the existence of libraries that already do almost everything for you. That is unquestionable. These days people don’t choose programming languages as much as they choose libraries and frameworks that already do most of the work for them, and that happen to be written in some programming language or another. One can argue that these powerful libraries and frameworks stand in the shoulders of a lot of work in programming languages that became invisible by design. But that work has already been done, to the point that these powerful libraries are already out there.
So where does this leave programming languages? Are we done yet?
After failing to find good papers about distributed systems testing for many months, yesterday I asked a question in Twitter:
This got many retweets and some interesting replies, so I’m going to summarize them here. Then I’ll explain a bit more about why I’m interested in this topic.
See my post at the IEEE Software Blog.
The recent scandal at UC Berkeley’s Astronomy department regarding a star Professor being accused of sexual harassment and consequently resigning from his position, has, once again, had me thinking about how institutions and organizations deal with sexual harassment. There are a few problems with how sexual harassment policies, and their enforcement, are handled, and I think we could do much better. We don’t have to reinvent the wheel to see how this could be done better: just look over the policies and procedures for conflict of interest. Let me argue here that there’s something missing in current sexual harassment policy designs — the concept of “sexual conflict.” Once that concept is spelled out, it’s easy to see how to handle these situations much better, and, better yet, to avoid horrible, not-good-for-anyone, full-blown sexual harassment situations, as what happened with Berkeley’s star astronomer.
I’ve been a Professor for almost 13 years. During these 13 years, I have seen investment in routine academic IT infrastructures decrease steadily, while at the same time being encouraged/pushed to use commercial infrastructures. Academic administrators seem to be mostly preoccupied with the 1% of academic work that requires high performance computing, large clusters and super high speed networks, and don’t pay much attention to the everyday needs of the other 99% of academic work. This puts research integrity at risk, but hey! — it’s hard to attract money for a vanilla storage system that is used for everyday computing, and for the sys admin that goes with it, especially when so many commercial cloud providers give things for free to Universities; you need to add bells and whistles and throw in a few buzz words like “cloud” and “big data” to get people impressed. Fair enough.
I finally got fed up with commercial solutions, for reasons that I explain later, and decided to set up my own IT infrastructure that fits exactly my needs and those of my group. I thought I’d write down my take on this. I suspect lots of colleagues have the same struggles. Continue reading
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!