The Art, Science, and Engineering of Programming journal is teaming up with the Onward! conference regarding essays. In this year’s Onward! Essays’ Instructions for Authors, authors are given the choice of publication venue. They can either do it as before — i.e. publish the essay in the Onward! proceedings book, published by the ACM; or they can submit the essay to a special issue of the Programming Journal, and present it at the Onward! conference. The submission deadline for this special issue is April 23, 2018, and the issue is scheduled to be published in September, 2018.
In other words, the live event Onward! will feature oral presentations of essays from two publications: an ACM conference proceedings monograph and a special issue of the Programming Journal.
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.