Your current filters are…
by Michael Ernst, David Lazar and Werner M. Dietl
Are you tired of null pointer exceptions, unintended side effects, SQL injections, concurrency errors, mistaken equality tests, and other run-time errors that appear during testing or in the field? A pluggable type system can guarantee the absence of these errors, and many more real, important bugs.
Are you a software architect who wants to be able to quickly and easily implement custom checks that prevent more errors at compile time? You need a framework that supports you in creating a formally correct code checker.
This presentation is aimed at both audiences. A pluggable type system can give a compile-time guarantee of important properties. We will explain what it is, how to use it, and even how to create your own. You can create a simple pluggable type-checker in 2 minutes, and you can enhance it thereafter.
The demo uses the Checker Framework, which enables you to create pluggable type systems for Java. It takes advantage of features planned by Oracle for Java 8, but your code remains backward-compatible. The pluggable type-checker can be run as part of javac or via an Eclipse plug-in, and integration with build tools such as Ant and Maven is provided. The tools are "freely available":http://types.cs.washington.edu/checker-framework/.
The Checker Framework provides 12 pluggable type systems that are ready to use, including nullness, immutability, and locking checkers. The presentation will first develop a simple declarative type checker that checks the consistency of method signature strings. The presentation will then discuss the design and usage of more advanced checkers.
The Checker Framework has found hundreds of bugs in over 3 million lines of open source code, including from Oracle, Google, Apache, etc. Overall, we found that the type checkers were easy to write, easy for novices to productively use, and effective in finding real bugs and verifying program properties, even for widely tested and used open source projects. It is easy to improve the quality of your Java code, and you can start using the Checker Framework today!
by Christoph Otto
As Parrot’s architect, I have an exciting view of the potential that Parrot has to change how developers look at dynamic languages. Unfortunately there are several barriers that Parrot's community needs to overcome to turn our potential awesomeness into actual awesomeness. I’ll talk about where Parrot’s been, what we’re doing now and where I see Parrot going in the future, both as a platform for language development and experimentation and as a product for embedding into other, sometimes surprising, applications. Satellites may be involved.
In the retrospective, I’ll touch on some of our successes and some of the problems we’ve dealt with. Rakudo Perl 6 has been an excellent user, both by requiring a stable platform for development and by exposing bugs in our code and processes, which I’ll cover. Our current policy and tools for dealing with deprecations were motivated largely by Rakudo. They’ve also necessitated a move to a more sophisticated automated testing infrastructure capable of intelligently tracking updates and dependencies and reporting failures. (currently a wip)
I’ll also talk about our series of low-level redesigns and rewrites known collectively as “Lorito” and what they’ll mean for Parrot’s users. Lorito is essentially a microcode-like set of very simple instructions on top of which the bulk of Parrot will be implemented. I’ll cover the design inspirations for Lorito and the benefits that our users. This will include a 10,000 foot view of Lorito and its meta-object model, based on Jonathan Worthington’s 6model work. I’ll take a high-level look at our roadmap and talk what’s been done and what remains.
If any time is left, I’ll talk about what we’ve got in the pipeline and show off what our hackers have been doing.
Our motto: *you snooze, you lose!*
Every paradigm eventually produces a language which pushes it to its puritan limit; lambda calculus let to church notation, in which even numbers are functions; symbolic list processing produced lisp, in which even code is a list; OOP gave us Smalltalk, in which everything is an object; the stack machine model produced forth in which everything a stack operation is; the modifiable storage location paradigm produced c, in which even the memory after a buffer...well, you get the idea.
But until about a week ago, the RESTful paradigm had failed to deliver on this fine tradition. There was no language in which every object of the denotational semantics was fully first-class and REASTful, with its own URI and CRUD. But now there is.
You have been warned.
21st–24th June 2011