Haskell in an Industrial Context

1. Haskell in an Industrial Context Andy Moran

2. Haskell, Galois, and the Future • Galois’ use of Haskell: why and where • Challenges in continuing to use Haskell • How do we meet these challenges • Some suggestions

3. Galois Summary • Mission: Advanced technology development for Information Assurance • Expertise • Crypto development and validation • Multi-level and cross-domain security • Secure middleware • Capabilities • High assurance engineering • Abstract modeling & analysis • Application of relevant theoretical research • Rapid prototype development • Domain-specific language development

4. Corporate Background • Founded in 1999; spun off from funded OGI research • Profitable last 8 quarters, >50% CAGR • Funding • Self-funded from revenues • 90% employee owned • 6 Active Projects • Mix of research and product development • Clients • U.S govt, multiple primes • 20 employees total • 15 technical staff • Additional contract employees and subcontractors

5. High Assurance Engineering • High Assurance means: • Formal and semi-formal specifications, designs, models • Formal and semi-formal correspondence arguments • Not necessarily mathematical proofs • Traditional testing • Many non-functional, non-technical requirements about: • Physical security of code • Software process documentation • Change management • Release management • High Assurance is not complete formal verification • Which is why we think we have a chance … • It’s all about gathering evidence that the product does what it should • It’s not about proving that it always does

6. Galois and Haskell • Galois’ focus is High Assurance development • With two exceptions, every project we’ve ever done or are now doing have uses Haskell • We delivered tools that are being used heavily: • Cryptol • GUI debugger for a specialized chip • Syntax extension tool for client’s own language (suped-up Happy + OCaml P4) • Our biggest project relies upon Haskell • High assurance arguments predicated upon use of Haskell • Another project is about Haskell • All others benefit from using Haskell

7. Why Haskell: Technical Benefits • Type system very strong, expressive • Type system exposes effects • Laziness encourages combinatorial design • Natural for many problems, particularly compilers • Haskell is very high-level • Promotes design-level programming • Haskell programs look like designs to non-practitioners • Enables us to try out creative solutions that might not be tractable with traditional languages • Able to express more complex algorithms • Design-level debugging • Trivial bugs disallowed by type system • Get straight to the real bugs • We’re very familiar with Haskell But these arguments do not a business case make!

8. The Big Win: High Assurance • Haskell is close to its semantics • Providing evidence for H.A. properties is possible • Haskell is amenable to formal techniques • Haskell’s type system can express and enforce desirable H.A. properties (such as data separation) • Good handle on H.A. correspondence arguments: • Specification, design, model: all in Haskell

9. Indirect Business Benefits • High productivity: • We can prototype products/tools very quickly • Competition: • Not many companies out there using Haskell as an enabling technology • Familiarity: • Most of Galois has been using Haskell since day 1 • Possibilities: • Allows greater scope for high assurance development • We can build in more functionality, to higher assurance • Quality of Staff: • Haskell practitioners tend to be extremely bright

10. It’s Not All Beer and Skittles … • There are problems with relying upon Haskell: • Technical issues • Support • Long-term viability • Customer needs • Customer perception • Staffing • Special government client needs

11. Development Issues • We’re surrounded by nails • When all you’ve got is a hammer … • Happily, it’s a Swiss Army hammer • Debugging can be a pain • Especially debugging in the IO monad • Existing debuggers tend not to support language extensions • Libraries only scratch library writers itch • Not designed with industrial applications in mind • Haskell encourages “abstraction addiction” • It’s very easy to get tied up in knots • Too much abstraction leads to maintenance headaches

12. Support Issues • Volunteer-based support for compiler only • Can’t depend on getting that showstopper fixed in time to meet your deadline • We push GHC to its limits, and so expose problems in the RTS • Without Sigbjørn Finne on the payroll, at least three of our projects would have been held up indefinitely • Threaded RTS, Asynchronous I/O for Windows, elusive GC bug • No 24 hour hotline • Only common platforms get any support • No industrial-grade tool support • Profilers limited; debuggers very limited • Libraries not tuned for performance • Libraries, language extensions documented mainly in research papers, if at all • GHC user manual gives reference-level documentation to extensions • IDEs very limited

13. Long-Term Viability • Reliant upon Simon and Simon • What if they start working on Word 2006? • Others starting to play larger role, but still small handful of key players • Still a research language • Exists to be test bed for experiments: • Language design (Template Haskell, exotic type systems) • Compiler implementation (eval-apply, CMM back-end) • This is A Good Thing • But we need a stable language too …

14. General Business Issues • Customers see problems: • How are they going to maintain the code we built for them? • Will this weird language even be around next year? • Customer perception: • “What’s Haskell?” • “What’s Functional Programming?” • “Functional programs are slow!” • “Why is it better than Java?” • “If it’s so great, why isn’t everyone using it?” • Staffing: • Not that many Haskell practitioners out there • Currently, we also need U.S. citizens

15. Government Issues • Pedigree of compiler source • Corralled repository • Who worked on it before corralling • Security of compiler source • Who has write access • How is repository protected • Physical (key card access to server room) • Network • How patches are vetted before being applied • How many “trusted” eyes have reviewed compiler source? • These questions are asked of any tool being used to develop sensitive applications • If tool source changes often, the burden is increased • Especially if we also need to update formal arguments and models each time there is a change

16. Are We Alone?

17. How Might We Solve These Problems Together?

18. What’s Been Tried Before?

19. Why Didn’t It Work?

20. Haskell Consortium • An affiliation of companies that use Haskell, together funding • Providing technical support for compilers and tools • Timely bug-fixes • Patch release management • Version, platform management • Keeping up with GHC patches • Evaluating GHC enhancements for inclusion • Pursuing industrial-grade development • Developing new tools • Enhancing existing tools • Developing experimental compilers, interpreters, run-time systems • Funding could be augmented: • Members’ clients? Government? Charity?