conclusion - university of edinburghhomepages.inf.ed.ac.uk/...lambdas-conclusion.pdf ·...

2
“Oracle_LaTeX/Mastering Lambdas/ Naftalin/ 182962-8” — 2014/8/28 — 17:04 Conclusion I should like to end this book on a personal note. I have long since lost count of the technologies that I have seen, over four decades, announced as the future of the industry, only to be forgotten within a year or two. A much smaller number have been slow burners: technologies that have grown a faithful following without ever reaching the commercial mainstream. In this category, one that stands out is functional programming, which has attracted some of the best minds and produced some of the best ideas in software development while remaining a minority interest. For myself, although I toyed with functional programming in the 1980s, I did not become a functional programmer. Instead, I followed the industry mainstream towards object-oriented programming, and eventually to Java. Nearly 20 years later, Java is, by most measures, the most popular programming language in the world. But, during the last few years, I have not felt complacent about the good fortune of my choice; a programmer who knows only Java would have been missing out on many useful new programming techniques that were appearing in rival languages. Many of these— for example, lazy evaluation, closures, and pattern matching—have their origins in functional languages. And this trend continues: functional programmers are optimistic about their future, above all because trends in hardware manufacturing technology and costs mean that massively concurrent systems are the future. Data immutability will be the key to reasoning about such systems. Java is not about to become a functional language, but Java programmers should be able to take advantage of some of the insights that functional programming has de- veloped. The changes of Java 8 are a first step in that direction. They bring immutability and lazy evaluation into practical Java programming and so address part of the great and ongoing challenge of partitioning tasks over multiple processors. Despite the com- mitment to backward compatibility that makes any change to a 20-year-old language so difficult, the Java design team has shown impressive ingenuity in integrating the 175

Upload: others

Post on 06-Jul-2020

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Conclusion - University of Edinburghhomepages.inf.ed.ac.uk/...lambdas-conclusion.pdf · “Oracle_LaTeX/MasteringLambdas/Naftalin/182962-8” — 2014/8/28 — 17:04 Conclusion Ishouldliketoendthisbookonapersonalnote.Ihavelongsincelostcountof

“Oracle_LaTeX/Mastering Lambdas/ Naftalin/ 182962-8” — 2014/8/28 — 17:04

Conclusion

I should like to end this book on a personal note. I have long since lost count ofthe technologies that I have seen, over four decades, announced as the future ofthe industry, only to be forgotten within a year or two. A much smaller number

have been slow burners: technologies that have grown a faithful following withoutever reaching the commercial mainstream. In this category, one that stands out isfunctional programming, which has attracted some of the best minds and producedsome of the best ideas in software development while remaining a minority interest.

For myself, although I toyed with functional programming in the 1980s, I did notbecome a functional programmer. Instead, I followed the industry mainstream towardsobject-oriented programming, and eventually to Java. Nearly 20 years later, Java is, bymost measures, the most popular programming language in the world. But, duringthe last few years, I have not felt complacent about the good fortune of my choice; aprogrammer who knows only Java would have been missing out on many useful newprogramming techniques that were appearing in rival languages. Many of these—for example, lazy evaluation, closures, and pattern matching—have their origins infunctional languages. And this trend continues: functional programmers are optimisticabout their future, above all because trends in hardware manufacturing technologyand costs mean that massively concurrent systems are the future. Data immutabilitywill be the key to reasoning about such systems.

Java is not about to become a functional language, but Java programmers shouldbe able to take advantage of some of the insights that functional programming has de-veloped. The changes of Java 8 are a first step in that direction. They bring immutabilityand lazy evaluation into practical Java programming and so address part of the greatand ongoing challenge of partitioning tasks over multiple processors. Despite the com-mitment to backward compatibility that makes any change to a 20-year-old languageso difficult, the Java design team has shown impressive ingenuity in integrating the

175

Page 2: Conclusion - University of Edinburghhomepages.inf.ed.ac.uk/...lambdas-conclusion.pdf · “Oracle_LaTeX/MasteringLambdas/Naftalin/182962-8” — 2014/8/28 — 17:04 Conclusion Ishouldliketoendthisbookonapersonalnote.Ihavelongsincelostcountof

“Oracle_LaTeX/Mastering Lambdas/ Naftalin/ 182962-8” — 2014/8/28 — 17:04

176 Mastering Lambdas

ideas of functional programming into a language designed on very different princi-ples. They have made a great success of this, the biggest single set of changes in Java’shistory.

I am excited about these changes, and I hope to have conveyed some of this excite-ment to you. I hope this book has helped you to understand Java’s new direction and,looking further, to become engaged with the future of the language. For the present,I would say this: programming should always be enjoyable, but you will find it muchmore enjoyable when you are writing the concise, readable, and performant code thatJava 8 supports. I would be delighted to think that this book had contributed to makingthat change in your programming life.

Maurice NaftalinPune, August 2014