Browse thread
Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data)
- Oliver Bandel
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Oliver Bandel <oliver@f...> |
| Subject: | Re: FP/IP and performance (in general) and Patterns... (Re: [Caml-list] Avoiding shared data) |
On Tue, Oct 04, 2005 at 07:45:12PM -0500, Brian Hurt wrote: [...] > The big advantage of FP programming IMHO is not performance, but instead > *correctness*. With today's multi-gigahertz machines with multi-gigabytes > of memory, performance isn't as critical as it used to be. But > correctness- especially automatically gaurenteed correctness on projects > spanning hundreds of thousands of lines of code and dozens of developers > maintained over decades of time- starts becoming critical. Yes, I agree on this. I get daily messages from an buglist-mailinglist, where most often things like typical memory-exploits are the reason of why a system or a process can be exploited. So, the typical "out of bounds" and "format string" problems are typical security risks. (Btw: is OCaml's format-string stuff from the Printf-module save in this respect?!) > I'd quite > happily trade off 10% performance for correctness, or even 50% > performance. Well, if the code with correctness is nearly as fast as the code without, it would be best. > > FP is a huge gain in correctness, because it allows me to *control > mutability*. If I pass a mutable data structure to a block of code there > is an instant implicit contract between the caller and the callee on how > (or wether) to modify the mutable data structure. It doesn't matter what > the contract is- wether it's to not modify the structure at all, to allow > optional modification (either unlimited or only in certain ways), or to > require certain modifications- a dependency between the two different > peices of code exists. And this dependency, this contract, is probably > undocumented and always unchecked by the compiler, which means it's a > maintaince nightmare waiting to happen. One peice of code gets modified > to violate the contract, perhaps even unknowingly, or perhaps due to some > changing requirement, and untouched code thousands of lines away suddenly > breaks. Yes, this is a very well description of the FP-advantages. Nevertheless, if a solution is too slow, it hinders people from adopting FPLs for their programmig, and software remains unsecure/unsafe, because they again and again will choose the unsafe langauges... :( Ciao, Oliver