|
|
|
|
| LEADER |
03095nmm a2200289 u 4500 |
| 001 |
EB000617143 |
| 003 |
EBX01000000000000000470225 |
| 005 |
00000000000000.0 |
| 007 |
cr||||||||||||||||||||| |
| 008 |
140122 ||| eng |
| 020 |
|
|
|a 9781447108412
|
| 100 |
1 |
|
|a Hammond, Kevin
|e [editor]
|
| 245 |
0 |
0 |
|a Research Directions in Parallel Functional Programming
|h Elektronische Ressource
|c edited by Kevin Hammond, Greg Michaelson
|
| 250 |
|
|
|a 1st ed. 1999
|
| 260 |
|
|
|a London
|b Springer London
|c 1999, 1999
|
| 300 |
|
|
|a XXVI, 496 p
|b online resource
|
| 505 |
0 |
|
|a I. Fundamentals -- 1. Introduction -- 2. Foundations -- 3. Programming Language Constructs -- 4. Proof -- 5. Realisations for Strict Languages -- 6. Realisations for Non-Strict Languages -- II. Current Research Areas -- 7. Data Parallelism -- 8. Cost Modelling -- 9. Shaping Distributions -- 10. Performance Monitoring -- 11. Memory Performance of Dataflow Programs -- 12. Portability of Performance in the BSP Model -- 13. Algorithmic Skeletons -- 14. Coordination Languages -- 15. Parallel and Distributed Programming in Concurrent Clean -- 16. Functional Process Modelling -- 17. Validating Programs in Concurrent ML -- 18. Explicit Parallelism -- III. Conclusion -- 19. Large Scale Functional Applications -- 20. Summary
|
| 653 |
|
|
|a Computer programming
|
| 653 |
|
|
|a Architecture, Computer
|
| 653 |
|
|
|a Programming Techniques
|
| 653 |
|
|
|a Computer System Implementation
|
| 700 |
1 |
|
|a Michaelson, Greg
|e [editor]
|
| 041 |
0 |
7 |
|a eng
|2 ISO 639-2
|
| 989 |
|
|
|b SBA
|a Springer Book Archives -2004
|
| 856 |
4 |
0 |
|u https://doi.org/10.1007/978-1-4471-0841-2?nosfx=y
|x Verlag
|3 Volltext
|
| 082 |
0 |
|
|a 005.11
|
| 520 |
|
|
|a Programming is hard. Building a large program is like constructing a steam locomotive through a hole the size of a postage stamp. An artefact that is the fruit of hundreds of person-years is only ever seen by anyone through a lOO-line window. In some ways it is astonishing that such large systems work at all. But parallel programming is much, much harder. There are so many more things to go wrong. Debugging is a nightmare. A bug that shows up on one run may never happen when you are looking for it - but unfailingly returns as soon as your attention moves elsewhere. A large fraction of the program's code can be made up of marshalling and coordination algorithms. The core application can easily be obscured by a maze of plumbing. Functional programming is a radical, elegant, high-level attack on the programming problem. Radical, because it dramatically eschews side-effects; elegant, because of its close connection with mathematics; high-level, be cause you can say a lot in one line. But functional programming is definitely not (yet) mainstream. That's the trouble with radical approaches: it's hard for them to break through and become mainstream. But that doesn't make functional programming any less fun, and it has turned out to be a won derful laboratory for rich type systems, automatic garbage collection, object models, and other stuff that has made the jump into the mainstream
|