Using Scala, does a functional paradigm make sense for analyzing live data?

For example, when analyzing live stockmarket data I expose a method to my clients

def onTrade(trade开发者_如何学Python: Trade) {
}

The clients may choose to do anything from counting the number of trades, calculating averages, storing high lows, price comparisons and so on. The method I expose returns nothing and the clients often use vars and mutable structures for their computation. For example when calculating the total trades they may do something like

var numTrades = 0

def onTrade(trade: Trade) {
    numTrades += 1
}

A single onTrade call may have to do six or seven different things. Is there any way to reconcile this type of flexibility with a functional paradigm? In other words a return type, vals and nonmutable data structures

You might want to look into Functional Reactive Programming. Using FRP, you would express your trades as a stream of events, and manipulate this stream as a whole, rather than focusing on a single trade at a time.

You would then use various combinators to construct new streams, for example one that would return the number of trades or highest price seen so far.

The link above contains links to several Haskell implementations, but there are probably several Scala FRP implementations available as well.

One possibility is using monads to encapsulate state within a purely functional program. You might check out the Scalaz library.

Also, according to reports, the Scala team is developing a compiler plug-in for an effect system. Then you might consider providing an interface like this to your clients,

def callbackOnTrade[A, B](f: (A, Trade) => B)

The clients define their input and output types A and B, and define a pure function f that processes the trade. All "state" gets encapsulated in A and B and threaded through f.

Callbacks may not be the best approach, but there are certainly functional designs that can solve such a problem. You might want to consider FRP or a state-monad solution as already suggested, actors are another possibility, as is some form of dataflow concurrency, and you can also take advantage of the copy method that's automatically generated for case classes.

A different approach is to use STM (software transactional memory) and stick with the imperative paradigm whilst still retaining some safety.

The best approach depends on exactly how you're persisting the data and what you're actually doing in these state changes. As always, let a profiler be your guide if performance is critical.