Big data is everywhere. Not surprisingly, it has come to our neck of the woods, too: research in software engineering, programming languages, and computer science in general. I’ve done a fair amount of work with it, and I suspect that will not stop. But do we really need big data? When is “big” really necessary and when is it, well, just a showoff? Here’s a reflection on this topic, just to reinforce the point that more is not always better. It all depends on what we are trying to achieve.
This post is primarily targeted at the Computer Science research communities that surround the ACM and the IEEE, but it applies to all tech communities that gravitate around conferences. I believe that an overwhelming majority of people in these communities is concerned about the effect that global warming is having on the Earth’s climate; many of us also know the urgency of the necessary measures. The question is: are we ready to act on what most of us believe, and reduce the amount of air travel we do for conferences? Or are we going to continue to live as if it doesn’t matter?
This post makes a radical proposal: let’s reduce and limit the number of physical conferences organized by the ACM and the IEEE down to a reasonable number. Something like one physical conference per SIG per year. Read on.
Learning how to write performant code is hard. Here are a few simple laws that I hope will convey the core of the matter. I’m calling them…
I’ve been relatively low key about something that I’m very excited about, so, after several months of planning, and a first, somewhat quiet, submission deadline, it’s time to release my enthusiasm. A group of us have started a new conference called <Programming> associated with a new open-access journal called The Art, Science and Engineering of Programming. Here are some FAQs about this initiative. Continue reading
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.