It's the after lunch slump (2 pm), so of course I'm attending the talk that will require attention - Daniel Poon's talk on number crunching. So: (they are using what they started with - VSE)

What does Smalltalk have to do with Numerically intensive tasks?

• Conventional Wisdom - slow, out of date
• Daniel says - look at what we do

Romax has been building in Smalltalk since 1994, and they think that Smalltalk lets them model mechanical behavior in ways that other technologies would not allow. Their customers include some of the biggest manufacturers (looks like a lot of vehicular/parts corps). From their website, they specialize in gearbox design. Their tools model various shaft arrangements - parallel, vertical, planetary (those are apparently technical descriptions).

F (Force) = k (stiffness) * x (deflection). They are solving for x. Given:

• Stiffness (stiffness of components)
• Forces (produced by engine, transmitted by the gearbox)
• Solve for Deflection (how the design will distort under use)

They do what's called VPD (Virtual Product Development). Typical transmission design (with real models) can take 3-4 years, and costs money for the parts. They can reduce that to 12-18 months using simulations.

Challenges:

• Customers always asking for more complex simulations
• That puts greater demands on performance
• The market demands shorter and shorter development cycles
• Which leads to Smalltalk

The main advantage they get from Smalltalk is immediate compilation and late binding. Late binding allows testing even when the system is broken. This gives them a step change in their programming style. Things they make use of?

• Double Dispatch
• Bouncing GUI code to test behavior immediately
• Extending the language/libraries as needed
• No need for multiple callbacks
• Resumable exceptions, the ability to customize handling of any and all exceptions

Daniel thinks Smalltalk could be widely accepted in the technical market. The market is huge and growing. Smalltalk is designed for the analysts own use - and Smalltalk has fundamental goodness for technical computing:

• Arbitrary length integers and fractions
• BlockClosures (pass equations into solvers)
• "Immediate" mode (doIt)

There are obstacles though - you'll need a Smalltalk coach for things like syntax (operator precedence, array syntax), lack of native solvers, floating point performance, and mixed language support. So on Floating point - Smalltalk is 70x slower than Fortran. So they use a layered architecture -

• product Model in Smalltalk
• Engineering calcs done in Fortran
• profiling shows that 60% of the time is spent on shuttling data back and forth - this is difficult to optimize

What they do is write everything Smalltalk - once it works, they profile and move critical bottlenecks to Fortran. The layered architecture really needs to be designed by the same team - at the same time - so that they mesh properly. What they did was create a single cross functional team, and instituted pair programming between the Smalltalk team and the Fortran team. This approach helped both with old hands and newbies - the new developers rapidly picked up domain expertise this way. [ed] - this is an old model - the master/apprentice thing. They've been doing this pairing approach for four years now.

There are terms for the two possible development modes - seperate teams (Chassis/Body), and the unified team described above (Monocoque). Why use the latter? The increasing demand for complex analysis pretty much requires it.

Bottom line - they think that Smalltalk gives them a competitive advantage over the other guys who use "mainstream" stuff. What could the Smalltalk community do to help? Take technical programming more seriously. Here's a picture of Daniel giving his talk: