I wanted to exercise, but I couldn't pass up the opportunity to hear Dave Thomas (Smalltalk Dave) give a talk. Dave is having a fun time offering to let us vote on which of his two presentations to give :) Heh - he's skipping the planned talk due to audience demand, and saying only that there are ways to introduce agile techniques into large organizations. Instead, we're going to take a look at where Dave thinks development is going in the next decade and a half.

Since leaving OTI, Dave has founded Bedarra Research Labs - he's looking to be able to do some development again, but current technology fads make him feel like he's had all his limbs hacked off. The problem: we're in an incredible complexity mess due to the badness of the current languages. This has generated a plethora of tools to try and compensate for that, but it only makes for a bigger pile. We have what Dave calls "Latent Technical Complexity".

Open SOurce from OS to Application allow every customer application to be "unique".

Why the latent complexity?

• Objects, components, interfaces, AOP, WS*, SOA (etc, etc)
• Enterprise Applications and the need for their customization
• Integration is difficult.
• Flagrant disregard for limited resources (Embedded Java, XML, SOAP)
• "Linux works because it's basically BSD circa 1980"

Lessons:

• KLOCS kill both performance and ability to evolve
• A Better Algorithm is better than optimization

There's a real skills gap: "everyone" knows Java: "Certification is a statement that you aren't competent". If you want to be where the action is, it's in the domain (business) side, not the development side.

MDD: The Ideal. Then there's the OMG (Object Losers Group, heh). way: MDA, or UML all the way down. This gives you development and debugging at the level of the abstraction. Interestingly, UML isn't even fully defined.

Heh - you aren't getting the real flavor of this talk - Dave is a truly funny guy.

The challenges of next generation applications: Business Driven vs. Technology Driven.

• Based on sound and deep understanding of the business
• complexity mandates development driven by business experts - domain fusion, probablities and fuzzy reasons)
• Support for high performance teams
• First time applications vs. traditional processes improvement

Real time business:development in real-time, execution in real time. They have masses of data and event streams. Important point: Processors, memory, bandwidth, and storage are "free" - Amazon ECL and S3, for instance.

So going back to games: Not just the fun stuff of the graphics and physics. You also have data persistence and versioning. You have distributed processing, visual content editors, scripting and compiler technologies, and UI work.

Game updates happen at high speed, they are distributed, and state changes hit multiple other objects. So back to MDD: a natural way of expressing application requirements in a disciplined and well understood "language" which models some aspect of the domain.

We want to work in a high level, domain oriented language - which will allow us to specify the domain more easily. Ideally, the developers would work with a domain (not a software engineer) expert who is versed in computational modeling. This is really about DSL (Steve Kelly!) - Domain Specific Languages.

Back to the future: We want languages that encourage "think and try it" - not ones that favor "design code and test". There are lots of examples of end user programming: Spreadsheets, MatLab, QBE tools, visual languages like ProGraph, DabbleDB, etc. There are lots of important things that aren't being taught anymore:

• Constraint Programming: ThingLab
• Dynamic Object Programming: Smalltalk, CLOS
• Logic Programming: Prolog
• Reactive Programming: Erlang

He listed others - point being, "fad" training is what Universities do now. Language design challenges:

• Expressiveness
• Readable and Writeable
• Strong specific vs. Strong generic (domain-wise)
• Uniform access to data (i.e., LINQ)
• Persistence
• Supporting multiple domains
• Supporting multiple paradigms