robert young
Posts: 361
Nickname: funbunny
Registered: Sep, 2003
|
|
Re: A practical point I think will be important
|
Posted: Sep 29, 2010 12:17 PM
|
|
> > I still wonder how this enthusiasm comports with > Amdahl's > > Law? Outside of servers, how many truly > > parallel/concurrent problems are there in > > client/standalone applications? > > Actually there are lots of parallel tasks in client or > standalone applications. > > You need to keep your UI responsive, so that should have a > dedicated thread. > Longer running work items started from the UI should run > in another thread. > Network interaction/downloads should also be on a > background threads, as should interaction with local > storage (which might very well be networked itself).
In real life, I don't see that happening with applications. Asking for a download, OK, I'll buy that.
But having tasks which are run at the behest of the user, but which the user is indifferent to when the task is completed, not so much. That indifference is key. With servers, each thread is run to satisfy (approximately) a user request, independent of other users; so there's no violation of Amdahl. With a true client/standalone application, either the user is working linearly (it's been found that humans are not all that adept at multi-tasking) in which case s/he'll want to know the result of step A before going on to step B, or s/he's running something like a VB/Access application; printing a G/L report while posting AR. But that's just a server, albeit single user.
> > So even there you get a lot of benefit from immutability > and other functional properties to avoid one task > corrupting another tasks data. > > Communication between the thread might be realized through > Software Transactional Memory, where updates may be run > multiple times if a conflict occurs. That can only be done > if your update functions are purely functional (no > side-effects). > > I'm sure there are more benefits that could be listed. > > The problem here is that these things require a change in > how developers think, and making that change is quite a > bit harder than changing software itself.
I argue that it's much more about how humans think. Again, we don't really multi-task efficiently. Expecting that we'll all of a sudden multi-task while interacting with applications smacks of Commander Data. Highly parallel/concurrent machines have existed in recent memory (well, for some of us), for not obscene amounts of money, and they failed simply because no one could figure out problems for them to solve. The web doesn't really change that, and the web is the only meaningful change to the world since those machines.
Still seems to me to be a solution in search of a problem. The simple way to provide an answer is to sketch how Word would be made better if it were written in an FP. Do that, and people will be convinced.
|
|