Sodbeans Wins JavaOne 2011 Duke's Choice Award
Sodbeans Wins JavaOne 2011 Duke's Choice Award
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
It feels great, and yes, I was completely shocked. We've been working on our project for a few years now, but some of the people that have won in the past are serious movers and shakers in industry and academia. To even be included in that group is a real honor for all of us on the Sodbeans project.
What's coming up next for the Sodbeans team and project?
Oh man, a ton. In terms of the project itself, Sodbeans 2.5 is going to be a really game-changing release for us, as our tools are starting to get up to commercial speed and our research and implementation effort is starting to really pay off. To be more specific, there are two major changes in this release:
This last summer, as we have continued working with schools for the blind across the United States, we've learned quite a bit about how best to help this group, and the 2.5 release will be the first to integrate everything we've learned about accessibility. Specifically, in Sodbeans 2.5, we have substantially changed how almost every component in Sodbeans will read to a blind user, including trees, lists, menus, visual components, and anything that we can get our hands on either through the NetBeans API or by reflection and hacks. We've also now completely replaced how screen readers interact with Sodbeans.
We do that for two reasons: 1) Since we have the NetBeans source, we can do way better screen reading than a screen reader can, and 2) Sodbeans is dramatically faster than using a screen reader and the Java Access Bridge.
We haven't had a chance to run formal benchmarks yet, as we are literally still building the 2.5 branch, but I'm guessing that the editor in Sodbeans is now probably 50x faster than in NetBeans with the Java Access Bridge and JAWS installed. That's huge. Just as important, users of Sodbeans not only get the speed increase, but we base what is actually read in the environment on a combination of formal empirical studies and observations with our user group. As such, we have a pretty good idea that the user interface is quite friendly to the blind. In short, I'm incredibly excited about what we've been able to accomplish in terms of accessibility for the next release.
- Introducing the Quorum Programming Language
So, it turns out that our lab has made a potentially significant discovery recently. For years, my team has been working on creating tools for the blind. We analyze those tools through a psychological model I invented a few years ago, which uses DNA processing algorithms to estimate how "comprehensible" a particular sound is in our environment. That sounds a little weird, but we've published on it in academic journals and it seems to work. That original work on those techniques was done in collaboration with Chris Hundhausen and Robert Patterson.
But I got to thinking: Blind environments have to make really careful use of language, otherwise our data shows they can be difficult to use, but what other tools do programmers use every day that need to do that? Programming languages. So, we've been working for a while to see if we can adapt our analysis for the blind to programming languages for almost two years now. We just published our first paper using the techniques, which is coming out in PLATEAU 2011, and it looks like the procedures are working. Here's a link to the paper, which the organizers have been nice enough to let me post early: http://www.cs.siue.edu/~astefik/papers/StefikPlateau2011.pdf
So, here's the point. For the last few years, by analyzing problems with accessibility, we may have accidentally stumbled on a new methodology for analyzing, in a real and scientifically defensible sense, whether particular programming language syntax/semantics/organization is good/bad for the humans that use them.
But, we didn't just do an analysis of some hypothetical language. We have actually gathered rigorous statistical analysis on programming language usage using a variety of techniques then gone ahead and build the language our results say "should" be easy to use. We call this language Quorum. Sodbeans 2.5 is going to include the first official release of Quorum as a Java Virtual Machine (JVM) language. This new language, which is adapted off of some of our previous interpreters (called Hop) will continue to have full accessibility support, like talking debuggers and all that.
To say the least, I'm personally really excited about our recent results. It turns out that maybe, just maybe, by focusing on blind accessibility, we have found on an out-of-the-box way to "think about" a major problem in computer science--that no one knows how programming language design affects human performance. Our language won't save the world in one release, but we think we now have a way forward for making progress, and my lab is dedicated to thoroughly collecting data and adjusting the language. For as long as I can get funding to support it, we're going to dedicate ourselves to studying this issue as scientifically rigorously as we can and to make adjustments to Quorum no matter where the results may lead. And of course, we will continue making the tools built through Quorum highly accessible, as that was our real inspiration.
How would your rate your time at JavaOne 2011?
Awesome, to say the least. I have especially enjoyed the talks by Charles Nutter, or as he puts it, the JRuby guy. Since we're making Quorum a JVM language, and have been spending a lot of time with bytecode lately, those talks were a lot of fun.
Will Sodbeans be back at future JavaOne conferences in a different setting/context?
Sure, I would love to be back. I've thought a lot about accessibility on the Java platform and have some ideas about how we could really shake things up, which people or devs at Oracle might be interested in. Or, maybe next year, I can share all of our data on human usage of programming languages. I imagine that stuff could be a real eye opener for folks, as most programming language designers have probably never had to defend language choices in a scientific, data-oriented, sense, and they might be interested. With language design, there are often real-world engineering decisions that get in the way of human usability, and that's a fact of life, but by looking at the data, it may give engineers some evidence as to what the choices "could" be.
Opinions expressed by DZone contributors are their own.