Dr. Guy L. Steele Jr. presented his new programming language Fortress. Is is loosely based on Fortran in that it is intended as a mathematical language. It is created with an intent of doing for Fortran what Java did for C, increase programmer productivity! The language is parallel by default but you can easily create sequential constructs. The language is created with a minimalist approach and it has a minimal kernel explicitly created for allowing you to create powerful libraries that blend in with the language. Fortress has explicit support for version control to allow early design mistakes to be corrected.
The language makes full use of unicode allowing you to use any mathematical notation that is appropriate. A wiki-like markup is also supported if you are restricted to ascii input. This syntax is however just a view of the actual program representation. The language has stole features from multiple languages. The type system is based on Traits which is basically multiple inheritance through the use of mix-ins as in Ruby. Everything, including primitives, is first-class in the language. The language has stolen both type inference and monads from Haskell. The language has also stolen contracts from Eiffel. Apart from contracts special constraints are also supported. Tests may be included with the code that make sure that the code conforms to the constraints.
Intentional Software and Charles Simonyi are creating a Language Workbench that will allow programmers and domain experts to create DSL that can be used by the domain experts to describe their knowledge as code. The programmer will then write code generators that will convert the DSL into source code that can be compiled and run. The DSL is represented as an internal structure that may be viewed and edited in many different notations. Examples of notations are: Sun Coding Standard, Mathematical, Spreadsheets and BNF. I like the approach but I have no idea when these tools will become available to us as programmers.
Pegasus: First Steps Towards a Naturalistic Programming Language want to allow programming in natural language to allow you to program in different languages. Like Intentional Software, they are using an internal structure to represent the program. Their approach seems to be pretty far from reality though.Joshua Bloch talked about API design. It was a good talk but he didn’t mention anything new. A good API should be:
- easy to learn
- easy to use
- hard to misuse
- easy to read (code that is written to it)
- easy to evolve
- appropriate to audience
- as small as possible
- unaffected by implementation details
- well documented, class – what does instance represent, method – pre/post-conditions and side-effects, parameters – units, form, ownership.
- concise, the client should not have to do anything the API can do.
- as immutable as possible.
Panel: Aspects and/versus Modularity raised the issue of DRY vs clear semantics. It made me more convinced that AOP is right. I’ll start using it as soon as possible!