functional programming

back to index

description: programming paradigm

131 results

Hands-On Functional Programming in RUST

by Andrew Johnson  · 29 May 2018  · 303pp  · 57,177 words

specific hot topic that we are recruiting an author for, or submit your own idea. Table of Contents Title Page Copyright and Credits Hands-On Functional Programming in Rust Packt Upsell Why subscribe? PacktPub.com Contributors About the author About the reviewer Packt is searching for authors like you Preface Who this

is for What this book covers To get the most out of this book Download the example code files Conventions used Get in touch Reviews Functional Programming – a Comparison Technical requirements Reducing code weight and complexity Making generics more generic Functions as values Iterators Compact legible expressions Strict abstraction means

safe abstraction Scoped data binding Algebraic datatypes Mixing object-oriented programming and functional programming Improving project architecture File hierarchy, modules, and namespace design Functional design patterns Metaprogramming Summary Questions Further reading Functional Control Flow Technical requirements Designing the

instead of stringly typed interfaces Using the heartbeat pattern for long running processes Validating input and output Finding and fixing bugs Metaprogramming Summary Questions Assessments Functional Programming – a Comparison Functional Control Flow Functional Data Structures Generics and Polymorphism Code Organization and Application Architecture Mutability, Ownership, and Pure Functions Design

Enjoy Leave a review - let other readers know what you think Preface Thanks for your interest in functional programming in Rust. Rust is a very young programming language and is particularly new to the functional programming community. Despite its age, the language provides a wealth of tools that are both practical and sophisticated

. In this book, we will introduce general functional programming principles and how they apply to Rust specifically. Our goal is to provide knowledge and a perspective on Rust that will outlast small changes to

Similarly, some concepts that are only briefly explained in the introductory material will be explained in detail. What this book covers Chapter 1, Functional Programming – a Comparison, introduces functional programming in Rust. Comparisons are drawn between functional style and other paradigms that are prevalent or influential to Rust. The chapter also serves as a

Functional Control Flow, introduces Rust control flow structures while explaining how they are relevant to the functional style of programming. The expression-centric nature of functional programming and Rust is illustrated through examples. Limiting as it may be, the chapter also begins an ongoing project using only the procedural expression style of

Structures, introduces the reader to the various, highly expressive data types available in Rust. Notably, the enum type is introduced, which holds particular significance in functional programming. The project continues to grow to incorporate a variety of these data types. Chapter 4, Generics and Polymorphism, explains the concepts of parameterization of data

thus no engineering procedure can capture the nuances of software development. In this chapter, we provide the best tools available, and specifically, the best that functional programming has to offer. Chapter 6, Mutability, Ownership, and Pure Functions, digs into some of the more unique features in Rust. This chapter introduces the concepts

spaghetti that a naive Rust programmer might generate when attempting to circumvent the rules of ownership in Rust. Chapter 7, Design Patterns, lists as many functional programming cheat codes that can fit into a single chapter. The concept of functors and monads are explained with examples and some casual definitions. The chapter

for Mac 7-Zip/PeaZip for Linux The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-Rust. In case there's an update to the code, it will be updated on the existing GitHub repository. We also have other

about our products, and our authors can see your feedback on their book. Thank you! For more information about Packt, please visit packtpub.com. Functional Programming – a Comparison Functional programming (FP) is the second most popular programming paradigm, behind only object-oriented programming (OOP). For many years, these two paradigms have been separated into

https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub, here: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Reducing code weight and complexity

Functional programming can greatly reduce the amount and complexity of code required to accomplish tasks. Particularly in Rust, proper application of functional principles may simplify the

<F,T>(f: F, x: T) -> T where F: Fn(T) -> T { f(x) } Functions as values Functions are nominally the big feature of functional programming. Specifically, functions as values are the keystone of the whole paradigm. Glossing over much detail, we will also introduce the term closure here for future

|x,y| x+y); Iterators Iterators are a common feature of OOP languages, and Rust supports this concept well. Rust iterators are also designed with functional programming in mind, allowing programmers to write more legible code. The specific concept emphasized here is composability. When iterators can be manipulated, transformed, and combined, the

or simple deadlock, then the compiler will stop you. We call this fearless concurrency. Algebraic datatypes In addition to structs/objects and functions/methods, Rust functional programming includes some rich additions to definable types and structures. Tuples provide a shorthand for defining simple anonymous structs. Enums provide a type-safe approach to

following code snippet, in intro_datatypes.rs: trait BehaviorOfShow { fn show(&self) -> String; } Mixing object-oriented programming and functional programming As mentioned before, Rust supports much of both object-oriented and functional programming styles. Datatypes and functions are neutral to either paradigm. Traits specifically support a hybrid blend of both styles. First, in

} } fn get_a(&self) -> u32 { self.a } fn get_b(&self) -> f32 { self.b } fn get_c(&self) -> String { self.c.clone() } } Adding support for functional programming onto an object is as simple as defining traits and methods that use functional language features. For example, accepting a closure can become a great

F: Fn(u32,f32,String) -> R { f(self.a, self.b, self.c.clone()) } } Improving project architecture Functional programs encourage good project architecture and principled design patterns. Using the building blocks of functional programming often reduces the number of design choices to be made in such a way that good options become obvious

extern crate package; use package::inner_module::f1; These are the basic building blocks of Rust modules, but what does this have to do with functional programming? Architecting a project in functional style is a process, and lends itself to certain routines. Typically, the project architect will start by designing the core

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Designing the program To design the program, let

the function would potentially call itself again. When a function calls itself, this is called recursion. Recursion is an extremely common and important pattern in functional programming. However, this specific type of recursion, known as tail recursion, is not recommended in Rust currently (see RFC #271 (https://github.com/rust-lang/

: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Adjusting to changing the scope of the project

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Staying productive during downtime There will be some

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Shipping a product without sacrificing quality The client

MotorController1 { ... } //Motor Controller 2 ... //Motor Controller 3 ... The entire code for these is present in the GitHub repository at: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST. Writing the buildings.rs module The building module is again grouped by type. There should be a common trait interface that is implemented

developer from certain classes of errors, such as double free memory or hanging pointers, but also create constraints that can feel unmerited at times. Functional programming may help ease some of this conflict by encouraging the use of immutable data and pure functions. In this chapter, we will look at a

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Recognizing anti-patterns of ownership Consider the following

problems. In the next chapter, we will formally explain many functional design patterns. This will be a good opportunity to learn the extent to which functional programming principles apply and are relevant to Rust. If nothing in the next chapter seems cool or useful, then the author has failed. Questions What

and ownership? How can you be sure that a function is safe? What is memory corruption and how would it affect a program? Design Patterns Functional programming has developed design patterns just like object-oriented or other communities. These patterns, unsurprisingly, make use of functions as a central concept. They also emphasize

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Using the functor pattern A functor is approximately

provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Using subprocess concurrency A subprocess is a command

through most problems. Using functional design for concurrency Concurrency forces the programmer to be more careful about information sharing. This difficulty coincidentally encourages good functional programming practices, such as immutable data and pure functions; when computation is not context-sensitive, it tends to also be thread-safe

are many trade-offs in concurrent programming. Letting the programmer make decisions regarding these trade-offs is the current state-of-the-art. So, from functional programming, what patterns have proven useful? There are many patterns for concurrent programming, but here we will introduce a few primitives: Actors: Threads and patterns

two threads sending messages back and forth. Is this really much different than any of the previous examples? There is a fairly common saying in functional programming that "a closure is a poor man's object, and an object is a poor man's closure". According to object-oriented programming, objects

. In the design pattern section, we introduced the actor design pattern. This popular technique combines some elements of object-oriented programming with other concepts from functional programming. The result is a programming tool designed specifically for complex resilient concurrency. In the next chapter, we will explore performance, debugging, and metaprogramming. Performance

examples provided: https://www.rust-lang.org/en-US/install.html This chapter's code is available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Writing faster code Premature optimization is the root

, address = 0x000000010000191c Now that our breakpoint is set, run the r command: (lldb) r Process 99468 launched: '/Users/andrewjohnson/subarctic.org/subarctic.org/Hands-On-Functional-Programming-in-RUST/Chapter09/target/debug/deps/performance_polynomial3-8048e39c94dd7157' (x86_64) Process 99468 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint

and practical considerations for Rust programming. Performance and debugging are certainly not problems that are exclusive to Functional Programming. Here we tried to introduce tips that are generally applicable but also highly compatible with functional programming. Metaprogramming in Rust may be considered a functional feature by itself. Logic programming and thereby derived functionality

book. There is an enormous amount of material available on these subjects and any path taken will surely further improve your understanding of Rust and functional programming. Questions How is release mode different from debug mode? How long will an empty loop take to run? What is linear time in Big

with multiple error conditions? What is a token tree? What is an abstract syntax tree? Why do procedural macros need to be compiled separately? Assessments Functional Programming – a Comparison What is a function? A function defines a transformation, accepts data, and returns the result of the transformation. What is a functor?

Functional Programming in Scala

by Paul Chiusano and Rúnar Bjarnason  · 13 Sep 2014

For more information on this and other Manning titles go to www.manning.com www.it-ebooks.info brief contents PART 1: INTRODUCTION TO FUNCTIONAL PROGRAMMING 1. What is functional programming? 2. Getting Started 3. Functional data structures 4. Handling errors without exceptions 5. Strictness and laziness 6. Purely functional state PART 2: FUNCTIONAL

-ebooks.info 1 P Preface P.1 About this book This is not a book about Scala. This book introduces the concepts and techniques of functional programming (FP)—we use Scala as the vehicle, but the lessons herein can be applied to programming in any language. Our goal is to give you

the foundations to begin writing substantive functional programs and to comfortably absorb new FP concepts and techniques beyond those covered here. Throughout the book we rely heavily on programming exercises, carefully chosen and

to further reading. P.2 How to read this book The book is organized into four parts, intended to be read sequentially. Part 1 introduces functional programming, explains what it is, why you should care, and walks through the basic low-level techniques of FP, including how to organize and structure small

can explore on your own if that interests you. Have fun and good luck. www.it-ebooks.info 5 1 What is Functional Programming? 1.1 The fundamental premise of functional programming Functional programming (FP) is based on a simple premise with far-reaching implications: We construct our programs using only pure functions. In other words

that we can still write all of the same programs—programs that can do all of the above and more—without resorting to side effects. Functional programming is a restriction on how we write programs, but not on what programs we can write. And it turns out that accepting this restriction is

3mIn practice, programmers don't spend time mechanically applying substitution to determine if code is pure—it will usually be quite obvious. 1.4 Why functional programming? We said that applying the discipline of FP buys us greater modularity. Why is this the case? Though this will become more clear over the

to be illustrative, and the sort of factoring we did here is something you've perhaps done many times before. It's been said that functional programming, at least in small examples, is just normal separation of concerns and "good software engineering". We will be taking the idea of FP to its

the outside that handles effects. We will return to this principle again and again throughout the book. 1.5 Conclusion In this chapter, we introduced functional programming and explained exactly what FP is and why you might use it. In subsequent chapters, we cover some of the fundamentals—how do we write

write programs in the Scala language just by combining pure functions. This chapter is mainly intended for those readers who are new to Scala, to functional programming, or both. As with learning a foreign language, immersion is a very effective method, so we will start by looking at a small but complete

many more examples of this throughout this book. www.it-ebooks.info 24 2.5.1 Annonymous functions Functions get passed around so often in functional programming that it's convenient to have a lightweight way to declare a function, locally, without having to give it a name. Scala provides a syntax

stick things together using the local 'rules of the universe' established by the type signature. The style of reasoning required here is very common in functional programming—we are simply manipulating symbols in a very abstract way, similar to how we would reason when solving an algebraic equation. EXERCISE 4 (hard): Let

of the style of reasoning and thinking you'll use when writing such functions. 2.7 Conclusion In this chapter we have learned some preliminary functional programming concepts, and enough Scala to get going. We learned how to define simple functions and programs, including how we can express loops using recursion, then

functional programming, how do we define them in Scala, and how do we operate over these data structures? In this chapter we will learn the concept of

structure and how to define and work with such structures. We'll use this as an opportunity to introduce how data types are defined in functional programming, learn about the related technique of pattern matching, and get practice writing and generalizing pure functions. This chapter has a lot of exercises, particularly to

concern of evaluation makes our descriptions more reusable than when these concerns are intertwined. This kind of separation of concerns is a central theme in functional programming. EXERCISE 4: Implement forAll, which checks that all elements in the www.it-ebooks.info 71 Stream match a given predicate. Your implementation should terminate

. These terms aren't that important to our www.it-ebooks.info 74 discussion, but you will hear them used sometimes in the context of functional programming. If you are curious to learn where they come from and understand some of the deeper connections, follow the references in the chapter notes. EXERCISE

by receiving it in their argument, and they write to the program state simply by returning a value. SIDEBAR Aren't imperative and functional programming opposites? Absolutely not. Remember, functional programming is simply programming without side-effects. Imperative programming is about programming with statements that modify some program state, and as we've seen

it's entirely reasonable to maintain state without side-effects. Functional programming has excellent support for writing imperative programs, with the added benefit that such programs can be reasoned about equationally because they are referentially transparent. We

little adventures. You don't need any special license to do this sort of exploration, and you don't need to be an expert in functional programming either. Just dive in and see what you find. Let's see if we can avoid the above pitfall of combining unit and get. If

to state and prove properties about an API. This certainly isn't something typically done in ordinary programming. Why is it important in FP? In functional programming, it is easy, and expected, that we will factor out common functionality into generic, reusable, components that can be composed. Side effects hurt compositionality, but

" is already a perfectly good name in common use. The name comes from category theory, a branch of mathematics that has inspired a lot of functional programming concepts. The name "monad" is intentionally similar to "monoid", and the two concepts are related in a deep way. See the chapter notes for more

and mutable state 14.1 Introduction In the first chapter of this book we introduced the concept of referential transparency, setting the premise for purely functional programming. We declared that pure functions cannot mutate data in place or interact with the external world. In the previous chapter on I/O, we learned

to some programs and not others. 14.2 Purely functional mutable state Up until this point, you may have had the impression that in purely functional programming we're not allowed to use mutable state. But if we look carefully, there is nothing about the definitions of referential transparency and purity that

intensionality www.it-ebooks.info 266 15 Stream processing and incremental I/O 15.1 Introduction We said in the introduction to part 4 that functional programming is a complete paradigm. Any program that can be imagined can be expressed functionally, including those that interact with the external world. But it would

the IO monad, we have to reason about our programs much like we would in ordinary imperative programming. We can do better. Not only can functional programs embed arbitrary imperative programs; in this chapter we show how to recover the high-level, compositional style developed in parts 1-3 of this book

small. While good design is always hard, over time, expressing code functionally becomes effortless. By this point, you have all the tools needed to start functional programming, no matter the programming task. FP is a deep subject, and as you apply it to more problems, new ideas and techniques will emerge. Enjoy

Artificial Intelligence: A Modern Approach

by Stuart Russell and Peter Norvig  · 14 Jul 2019  · 2,466pp  · 668,761 words

to Cox’s theorem. IJAR, 34, 3–24. Horning, J. J. (1969). A Study of Grammatical Inference. Ph.D. thesis, Stanford University. Horswill, I. (2000). Functional programming of behavior-based systems. Autonomous Robots, 9, 83–93. Horvitz, E. J. (1987). Problem-solving design: Reasoning about computational value, trade-offs, and resources. In

The IDA Pro Book

by Chris Eagle  · 16 Jun 2011  · 1,156pp  · 229,431 words

On Lisp: Advanced Techniques for Common Lisp

by Paul Graham  · 8 Sep 1993  · 423pp  · 21,637 words

Why Lisp (or When) Functions Functions as Data Defining Functions Functional Arguments Functions as Properties Scope Closures Local Functions Tail-Recursion Compilation Functions from Lists Functional Programming Functional Design Imperative Outside-In Functional Interfaces Interactive Programming Utility Functions Birth of a Utility Invest in Abstraction Operations on Lists Search Mapping I/O

begins with several chapters on functions. Chapter 2 explains what Lisp functions are and the possibilities they offer. Chapter 3 then discusses the advantages of functional programming, the dominant style in Lisp programs. Chapter 4 shows how to use functions to extend Lisp. Then Chapter 5 suggests the new kinds of abstractions

are so powerful, for example. Most of the techniques described in this book depend on the ability to write programs which manipulate Lisp expressions. * * * 3. Functional Programming The previous chapter explained how Lisp and Lisp programs are both built out of a single raw material: the function. Like any building material, its

overall shape of the building what it's made of. The character of Lisp functions has a similar influence on the structure of Lisp programs. Functional programming means writing programs which work by returning values instead of by performing side-effects. Side-effects include destructive changes to objects (e.g. by rplaca

to read, test, and debug. Lisp programs have not always been written in this style, but over time Lisp and functional programming have gradually become inseparable. An example will show how functional programming differs from what you might do in another language. Suppose for some reason we want the elements of a list in

Lisp has it built-in. It is worth looking briefly at this function, because it is one that often brings to the surface misconceptions about functional programming. Like good-reverse,the built-in reverseworks by returning a value--it doesn't touch its arguments. But people learning Lisp may assume that, like

, remove, or substitute. If you want side-effects, use setq on the return value. This very rule suggests that some side-effects are inevitable. Having functional programming as an ideal doesn't imply that programs should never have side-effects. It just means that they should have no more than necessary. It

(x) (values x (sqrt x) (expt x 2))) POWERS > (multiple-value-bind (base root square) (powers 4) (list base root square)) (4 2.0 16) Functional programming is a good idea in general. It is a particularly good idea in Lisp, because Lisp has evolved to support it. Built-in operators like

, like values and multiple-value-bind, have been provided specifically to make functional programming easier. 3.2 Imperative Outside-In The aims of functional programming may show more clearly when contrasted with those of the more common approach, imperative programming. A functional program tells you what it wants; an imperative program tells you what to do

on dry land--if you use skates. Till then you will be left wondering what people see in this sport. What skates are to ice, functional programming is to Lisp. Together the two allow you to travel more gracefully, with less effort. But if you are accustomed to another mode of travel

more as a source of contagion than a source of pleasure. Usually it would be bad style to write such a macro. The ideal of functional programming applies as well to macros: the preferred way to communicate with a macro is through its parameters. Indeed, it is so rarely necessary to use

they return in much the same way that functions return values. In fact, with the exception of being nondeterministic, ATNs behave a lot like a functional programming language. The ATN defined in Figure 23.1 is nearly the simplest possible. It parses noun-verb sentences of the form "Spot runs." The network

Masterminds of Programming: Conversations With the Creators of Major Programming Languages

by Federico Biancuzzi and Shane Warden  · 21 Mar 2009  · 496pp  · 174,084 words

the official runtime semantics actively discourage cleverness in the compiler like parallelizing loops or turning recursion into loops. Python probably has the reputation of supporting functional programming based on the inclusion of lambda, map, filter, and reduce in the language, but in my eyes these are just syntactic sugar, and not

made better. And then over time the code is used in unexpected circumstances, and more of the decisions look bad. Would functional programming help? Peter: If the question is whether functional programs, being more mathematical, would somehow express results better than ordinary programs, I don’t see a big difference. Any single-assignment

version 1, Lua has had functions as first-class values, and they proved to be really useful, even for “regular” programmers without previous experience with functional programming, but without closures, the use of first-class functions is somewhat restricted. By the way, the term closure refers to an implementation technique, not

do you develop a language in a team? Simon Peyton Jones: We were fortunate in having a shared goal (that of developing a common lazy functional programming language) and having broadly compatible technical agendas. Our paper on the history of Haskell[10] describes various tactics that we employed (face-to-face

care we took is reflected strongly in the quality of the design. It sounds quite dialectical, doesn’t it: thesis + antithesis = synthesis. Trajectory of Functional Programming What makes functional programming languages different from other languages? Simon: Oh, that’s easy: control of side effects. John: Well, careful control of side effects, obviously. First-

afraid I’m just not clever enough to make side-effecting code work! (Wait a minute, perhaps imperative programming would be easier without years of functional programming experience….) :-) Oh, and did I mention easy parallelization? Paul: Sanity, and the joy of solving a puzzle! :-) John mentioned parallelism. Are there other changes

in the computer field that make functional programming even more desirable and needed than before? Simon: I believe that a long-term trend is that it will become more and more important to

lookup :: Map -> Key -> Maybe Item where the Maybe data type expresses the possibility of failure, through the medium of values. How does debugging change in functional programming? Paul: Well, first of all, I’ve always felt that the “execution trace” method of debugging in imperative languages was broken, even for imperative programs

evaluation process. Instead, people have designed debuggers such as Buddha based on “data dependencies,” which is much more in line with the declarative principles of functional programming. But, perhaps surprisingly, in all my years of Haskell programming, I have never in fact used Buddha, or GHC’s debugger, or any debugger

variables suggestive names will not help the computer “understand” their program and fix their bugs! I think the myth arises because imperative programmers find functional programming more difficult than they expect. Experienced programmers are used to picking up new languages easily, because they can directly transfer basic concepts such as variables

programming. That difference makes it hard to accept, hard to learn, and hard to support (with libraries, implementations, etc.). Is that situation changing? Simon: Functional programming is a long-term bet. It’s a radically different way to think about the whole enterprise of programming. That makes it hard for people

the level of interest is rising fast, and all kinds of unexpected applications are popping up. Likewise OCaml. Multicores provide a unique opportunity for functional programming—there’s a widespread recognition that we don’t know how to program them, and many, many people are starting to consider alternative ways of

widely used languages, including Cayenne, Clean, Mercury, Curry, Escher, Hal, and Isabelle. John: In addition: anonymous delegates in C# and list comprehensions in Python. Functional programming ideas are popping up all over the place. Paul: I have read many accounts of people who learn Haskell but rarely use it in their

Simon: There already are competing implementations that tend to be a bit more specialized toward particular areas. In fact, just recently at ICFP, the functional programming conference a couple of weeks ago, we shifted gears. Rather than trying to produce a single monolith, which is Haskell Prime, we’re instead going

lessons about the invention, further development, and adoption of your language say to people developing computer systems today and in the foreseeable future? Simon: Functional programming is a laboratory where lots and lots of interesting ideas are explored. Because the basic setting is simpler, we can go a lot further in

remarkable variety of applications. Do paradigms besides OOP influence the way a programmer designs and thinks? Robin: Yes, I think that logic programming and functional programming have had that influence. I hope that the paradigms of process calculi also have an influence. They certainly did in Lotos—a specification language—and

co-editor of the first Haskell Report, and has written a popular tutorial and a textbook on the language. His early work also involved parallel functional programming, abstract interpretation, and declarative approaches to state. More recently, Professor Hudak has been involved in the design of domain-specific languages for a diverse

the world—including both Phil Wadler and Simon Peyton Jones. The annual research group workshops became well known, and eventually developed into the Trends in Functional Programming symposium, which continues to this day. But in 1992, John was offered a Chair at Chalmers, and took the opportunity to return to Sweden.

London, and nine years as a professor at Glasgow University, before moving to Microsoft Research (Cambridge) in 1998. His main research interest is in functional programming languages, their implementation, and their application. He has led a succession of research projects focused around the design and implementation of production-quality functional-language

and garbage collection. He is particularly motivated by direct use of principled theory to practical language design and implementation—that’s one reason he loves functional programming so much. Brian Kernighan received his B.A.Sc. from the University of Toronto in 1964 and a Ph.D. in electrical engineering from

most-cited authors in computer science, is a winner of the POPL Most Influential Paper Award, served as editor-in-chief of the Journal of Functional Programming, and served on the Executive Committee of the ACM Special Interest Group on Programming Languages. His papers include “Listlessness is better than laziness,” “How

on Pattern Matching: Where do you find the match to an empty array (Falkoff), Elementary Principles A Programming Language (Iverson), Paper and Pencil abstraction in functional programming, A Functional Team in SQL, Feedback and Evolution agents, Beyond Informatics Aho, AWK Aho-Corasick algorithm, Computer Science automata theory, Computer Science command-line

data sizes, Programming by Example debugging code C#, C# design considerations for, Designing a Language ease of, Language Design, Designing a New Language functional programming and, Trajectory of Functional Programming language design considerations for, Theory and Practice, Growing a Language Lua, Language Design PostScript, Interfaces to Longevity Python, Multiple Pythons debugging languages, The

links to informatics, Beyond Informatics programming as, Learning and Teaching error messages in Lua, Language Design quality of, Theory and Practice errors handling, Trajectory of Functional Programming language design reducing number of, Theory and Practice reduced by language design, Theory and Practice Excel, Feedback and Evolution extensibility, The Language F Falkoff,

Language functional programming, Trajectory of Functional Programming–The Haskell Language, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, The Haskell Language abstraction in, Trajectory of Functional Programming concurrency and, A Bit of Reusability debugging in, Trajectory of Functional Programming error handling in, Trajectory of Functional Programming longevity of, Trajectory of Functional Programming parallelism and, Trajectory of Functional Programming popularity

of, Trajectory of Functional Programming

Scala for, Concurrency side effects, Trajectory of Functional Programming

, Trajectory of Functional Programming

, Trajectory of Functional Programming

, Formalism and Evolution, Formalism and Evolution influencing other languages, The Haskell Language list comprehensions, The Haskell Language team designing, A Functional Team–Trajectory of Functional Programming, Trajectory of Functional Programming type system for, The Haskell Language, The Haskell Language, The Haskell Language, The Haskell Language, The Theory of Meaning Hejlsberg, C# backward compatibility

Afternoon HOPL-III: The development of the Emerald programming language, OOP and Concurrency HTML, Standard Wishes Hudak functional programming, Trajectory of Functional Programming–The Haskell Language, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming, The Haskell Language Haskell’s influence on other languages, The Haskell Language language design influencing software design,

The Haskell Language teaching programming and computer science, Spreading (Functional) Education Hughes functional programming, Trajectory of Functional Programming–The Haskell Language, Trajectory of Functional Programming

, Trajectory of Functional Programming, Trajectory of Functional Programming, Trajectory of Functional Programming

or Simplicity Javadoc tool, Designing a Language JavaScript, Interfaces to Longevity, Standard Wishes JIT, Power or Simplicity Jones formal semantics, Formalism and Evolution functional programming, Trajectory of Functional Programming, Trajectory of Functional Programming teaching computer science, Spreading (Functional) Education JVM new languages built on, Designing a Language popularity of, A Matter of Taste K kanji

as object-oriented language, Language Design words used in languages, Language Design L language toolkit, The Forth Language and Language Design lazy evaluation, Trajectory of Functional Programming, The Haskell Language LCF, The Soundness of Theorems limits of, The Soundness of Theorems legacy software, Bits That Change the Universe, Theory and Practice

Universe C, Waiting for a Breakthrough creativity in programmers, Bits That Change the Universe error messages, Theory and Practice extensible languages, Waiting for a Breakthrough functional programming, Bits That Change the Universe general-purpose languages, Waiting for a Breakthrough implementation affecting language design, Theory and Practice language design, Theory and Practice,

Exploring Python

by Timothy Budd  · 17 Feb 2009  · 263pp  · 20,730 words

Contents Part I. Basic features of Python 1. Interactive Execution 2. Programs in Python 3. Functions 4. Strings 5. Dictionaries 6. Files 7. Classes 8. Functional Programming 9. Object-Oriented Programming 10. Modules 11. Advanced Features Part II. [ I will be adding a few more to this list as they are developed

only one data field, and a different answer if an instance of D has two data fields. Exploring Python – Chapter 7 – Classes 15 Chapter 8: Functional Programming Programming a computer is a complicated task, and like most complicated tasks there are many different ways to think about the process. The term language

the imperative paradigm not in the way the computer operates, but in the way that the programmer thinks about the task of programming. The Functional Programming Paradigm The term functional programming does not simply imply programming with functions, but is used to describe an alternative to the imperative programming paradigm. As the name suggests

, the creation of functions is an important part of functional programming. But simply defining a few functions does not mean that you are programming in a functional style. There were many functions defined in earlier chapters

, and yet we did not call those functional programs. The key characteristic of a program developed in the functional programming style is that it creates new values by a process of transformation. Generally values are represented as lists, or dictionaries

of transformation can be subdivided into several common forms. The three most common varieties of transformation are mapping, filtering, and reduction. Exploring Python – Chapter 8: Functional Programming 1 A mapping is a one to one transformation. Each element in the source is converted into a new value. The new values are gathered

] print map(lambda x : x * 2 + 1, a) 5, 7, 9, 11] print filter(lambda x: x % 2 == 0, a) 4] Exploring Python – Chapter 8: Functional Programming 2 >>> print reduce(lambda x, y: x + y, a) 15 Notice that the original list, held in the variable named a, remains unchanged. The functions

, and returns a Boolean value. A one-argument function that returns a Boolean result is termed a predicate. List Comprehensions An even simpler form of functional programming is provided by a list comprehension. Instead of defining a list by a sequence of elements, lists can be characterized by a process. This process

other elements of the list. >>> [a[i] for i in range(0,len(a)) if i%2 == 0] [1, 3, 5] Exploring Python – Chapter 8: Functional Programming 3 Operation on dictionaries are often performed by selecting values from the range of keys, then returning the items with the selected key: >>> d = {1

= [] # build an empty set for x in a: if x in b: instersect.append(x) print “intersection is “, intersect If you were thinking in a functional programming fashion, you would notice that the intersection is a subset of the elements in either set. This naturally suggests the result can be formed using

mistake. It is relatively easy to look at the expression, understand what it is doing, and verify that it is correct. Exploring Python – Chapter 8: Functional Programming 4 The list comprehension form is even shorter. There is no need for the lambda expression, as the if keyword is performing a similar task

a function: def intersect(a, b): return [x for x in a if x in b] Notice the features that make this solution characteristic of functional programming. Most importantly, rather than making a succession of small changes to a value, the function is building the result as a transformation of one or

multiple of the number. Repeat until the list is empty. We describe the thought process you might follow in creating a program written in the functional programming style to perform this task. It is easy enough to create a list of values from two onwards using the range function: >>> a = range(2

can be written as follows: >>> print filter(lambda x: x % a[0] != 0, a[1:]) [3, 5, 7, 9, 11, 13] Exploring Python – Chapter 8: Functional Programming 5 Alternatively, you could use list comprehensions: >>> print [ x for x in a[1:] if x % a[0] != 0] [3, 5, 7, 9, 11, 13

otherwise if x < a[0], then [x] + a is an insertion otherwise append a[0] to the insertion(x, a[1:]) Exploring Python – Chapter 8: Functional Programming 6 This yields the following recursive function: def insertion (a, x): if not a: # that is, if a is empty return [ x ] elif x < a

illustration of how a problem can be described as a transformation. Quick sort is a recursive algorithm that works by (a) Exploring Python – Chapter 8: Functional Programming 7 selecting some element, termed the pivot, (b) dividing the original list into three parts, namely those that are smaller than the pivot, those equal

) 15 If you want to give this a simple name you can wrap the call on reduce inside a function definition: Exploring Python – Chapter 8: Functional Programming 8 def sum(a): return reduce(lambda x, y: x + y, a) To form the product of a list you need the three argument form

of operations that can be performed using functional techniques. Once you start to think about how a problem can be addressed Exploring Python – Chapter 8: Functional Programming 9 using techniques such as mapping, filtering and reduction you will find many other applications. Computing Variance of a List The computation of the variance

correct. Combining Functional and Object-Oriented Programming It is possible to write programs entirely in a functional fashion. However, it is more common to use functional programming features, and combine them with other techniques. An individual function might be written in a functional fashion, while the remainder of a program is imperative

], [9, 8, 7]) 1 Sections marked with an asterisk indicate optional or advanced material, and can be skipped on first reading. Exploring Python – Chapter 8: Functional Programming 10 [10, 10, 10] If either list is shorter than the other the shorter list is padded with elements of value None. List comprehensions can

of the values c. A list where each element is larger by one than the corresponding element in the original list Exploring Python – Chapter 8: Functional Programming 11 3. Let a be the list of values produced by range(1, 11). Using the function filter and a lambda argument, write an expression

values in a that are less than or equal to 5 The squares of those values in a that are even Exploring Python – Chapter 8: Functional Programming 12 12. Write three versions of a function that will take a list as argument, and return a list containing the cubes of the elements

as a list comprehension. The difference consists of the elements in the first list that are not part of the second. Exploring Python – Chapter 8: Functional Programming 13 19. Using the difference function you wrote in the previous question, define a function that returns the union of two sets that are represented

paragon of clarity in Python programming. >>> f = lambda x, y: (((x < y) and [x]) or [y])[0] >>> f(0, 4) 0 Exploring Python – Chapter 8: Functional Programming 14 Chapter 9: Object-Oriented Programming Chapter 8 introduced the notion of a programming paradigm. The term paradigm, you will recall, refers to the mental

, a program is viewed as a collection of computing agents, each of which is providing a service that can be used by the others. The functional programming model requires the ability to create functions, but the paradigm is much more than the simple use of this mechanism. In a similar fashion, the

that this program could be improved. More importantly, the purpose of this example is to illustrate functional programming techniques, and in particular the use of list comprehensions in Python as an example of the ideas of functional programming. Representation [[0,0,0,0,9,0,5,8,2], [0,0,0,0,0,2

been to discuss a Sudoku solver, since this program works only with very simple puzzles. Instead, our purpose has been to illustrate the idea of functional program as represented by list comprehensions in the language Python. The advantages of this style of programming are numerous. Functions tend to be short, faster than

Reversing: Secrets of Reverse Engineering

by Eldad Eilam  · 15 Feb 2005  · 619pp  · 210,746 words

of it. In the software world, this translates to seemingly innocent files that actually contain some kind of malicious code underneath. Most Trojans are actually functional programs, so that the user never becomes aware of the problem; the functional element in the program works just fine, while the malicious element works behind

The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal

by M. Mitchell Waldrop  · 14 Apr 2001

function that took the definition of any other function as input and then executed that function. By no coincidence, McCarthy imple- mented this kind of functional programming in Lisp using the notation of the "lambda calcu- lus," which Alonzo Church had created twenty years earlier to solve the decidabihty problem, and which

Scala in Depth

by Tom Kleenex and Joshua Suereth  · 2 Jan 2010  · 554pp  · 108,035 words

7. Using implicits and types together Chapter 8. Using the right collection Chapter 9. Actors Chapter 10. Integrating Scala with Java Chapter 11. Patterns in functional programming Index List of Figures List of Tables List of Listings Table of Contents Copyright Brief Table of Contents Table of Contents Foreword Preface Acknowledgments About

this Book About the Cover Illustration Chapter 1. Scala—a blended language 1.1. Functional programming meets object orientation 1.1.1. Discovering existing functional concepts 1.1.2. Examining functional concepts in Google Collections 1.2. Static typing and expressiveness

classes 10.4. Annotate your annotations 10.4.1. Annotation targets 10.4.2. Scala and static fields 10.5. Summary Chapter 11. Patterns in functional programming 11.1. Category theory for computer science 11.2. Functors and monads, and how they relate to categories 11.2.1. Monads 11.3. Currying

Scala—that Scala is a blending of concepts that achieve a greater whole when combined. In particular, three dichotomies are discussed: static typing versus expressiveness, functional programming versus object-oriented programming, and powerful language features versus dead simple Java integration. Chapter 2 is a discussion of the core rules of Scala. These

this chapter provides a few simple rules that help avoid these issues. Chapter 11 takes concepts from category theory and makes them practical. In pure functional programming, a lot of concepts from category theory have been applied to code. These are akin to object-oriented design patterns, but far more abstract.

While they have terrible names, as is common in mathematics, these concepts are immensely useful in practice. No coverage of functional programming would be complete without a discussion of some of these abstractions, and Scala in Depth does its best to make these concepts real. Code downloads

into the Java programming language. Scala was an offshoot from the Funnel language, an attempt to combine functional programming and Petri nets. Scala was developed with the premise that you could mix together object orientation, functional programming, and a powerful type system and still keep elegant, succinct code. It was hoped that this

this mixture of concepts. Scala attempts to blend three dichotomies of thought into one language. These are: Functional programming and object-oriented programming Expressive syntax and static typing Advanced language features and rich Java integration Functional programming is programming through the definition and composition of functions. Object-oriented programming is programming through the definition

based project. Let’s take a deeper look at the blending of paradigms in Scala. 1.1. Functional programming meets object orientation Functional programming and object-oriented programming are two different ways of looking at a problem. Functional programming puts special emphasis on the “verbs” of a program and ways to combine and manipulate them. Object

type of Food, which it can then eat. The code focuses on the nouns and their actions: Cat.eat(), Cat.catch(...). In functional programming, the focus is on the verbs. Functional programming approaches software as the combination and application of functions. It tends to decompose software into behaviors, or actions that need to be

bottom-up fashion. Functions are viewed in a mathematical sense, purely operations on their input. All variables are considered immutable. This immutability aids concurrent programming. Functional programming attempts to defer all side effects in a program as long as possible. Removing side effects makes reasoning through a program simpler, in a formal

The eat method is defined as taking a CatWithPrey (a cat needs something to eat) and returns a FullCat (because it’s no longer hungry). Functional programming makes more use of the type system to describe what a function is doing. The catch and eat methods use the type signatures to define

method. Finally, the story function is called with a Cat and a Bird and the result is the output of the story: a full cat. Functional programming and object orientation offer unique views of software. It’s these differences that make them useful to each other. Object orientation can deal with composing

the nouns and functional programming can deal with composing verbs. In the example, the functional version was built by composing a set of functions that encompassed a story and then

approaches are useful in designing software. Object orientation can focus on the nouns of the system and functional programming can compose the verbs. Table 1.1. Attributes commonly ascribed to object-oriented and functional programming Object-oriented programming Functional programming Composition of objects (nouns) Composition of functions (verbs) Encapsulated stateful interaction Deferred side effects Iterative algorithms

and the Google Collections library is very functional in design. Let’s look at these common Java libraries and see how Scala’s blend of functional programming with object orientation can enhance these Application Program Interfaces (APIs). 1.1.1. Discovering existing functional concepts Many modern API designs have been incorporating functional

ideas without ascribing them to functional programming. For Java, things such as Google Collections or the Spring Application Framework make popular functional concepts accessible to the Java developer. Scala takes this further

traits allow composition. By the time you’re finished reading this book, you’ll be able to approach the design of this interface completely differently. Functional programming also shines when used in a collections library. The Ruby and Python programming languages support some functional aspects directly in their standard library collections. For

Java users, the Google Collections library bring practices from functional programming. 1.1.2. Examining functional concepts in Google Collections The Google Collections API adds a lot of power to the standard Java collections. Primarily it

should also be T => Boolean. The predefined predicates should also have a type T => Boolean. We’ve now started to delve into the realm of functional programming. We’re defining first-class functions and combining them to perform new behaviors. You’ll notice the or method take two predicates, f1 and f2

the type system. Scala has put forth a lot of effort to reduce the overhead for generics in daily usage. Functional programming is more than combining functions with other functions. The essence of functional programming is delaying side effects as long as possible. This predicate object defines a simple mechanism to combine predicates. The

to the Iterables object. This distinction is important. Complex predicates can be built from simple predicates using the helper methods defined on the object predicates. Functional programming grants the means to defer state manipulation in a program until a later time. It provides a mechanism to construct verbs that delay side effects

utilized in our day-to-day jobs with little cost. As Scala blends various concepts, users of Scala will find themselves striking a balance among functional programming techniques, object orientation, integration with existing Java applications, expressive library APIs, and enforcing requirements through the type system. Often the best course of action

once constructed. 2.3. Prefer immutability Immutability, in programming, refers to the unchanging state of objects after construction. This is one of the capstones of functional programming and a recommended practice for object-oriented design on the JVM. Scala is no exception here and prefers immutability in design, making it the default

portion of code required to interact with the library in Java and exposing a Scala-friendly interface is the only solution. The next chapter covers functional programming, which is a way of writing programs that may be foreign to those of us coming from an object-oriented or imperative background. Let’s

look into a world where no effects are side effects and operations are deferred as long as possible. Chapter 11. Patterns in functional programming In this chapter Functors, monads, and applicative functors Configuring applications using applicative style Composing workflows using monads and for expressions

Functional programming is the practice of composing programs using functions. It’s an area of software design and architecture that has been neglected in mainstream books

and classes since the emergence of object-oriented programming. Functional programming offers a lot to the object-oriented developer and can nicely complement standard object-oriented practices. Functional programming is a relatively large topic to try to compress into a single chapter. Instead, this chapter introduces

a few key abstractions used in functional programming and demonstrates their usage in two different situations. The goal is to show

one of the many styles of functional programming, rather than turn you into an expert functional programmer. First, a discussion on some fundamental

concepts behind the patterns in functional programming. 11.1. Category theory for computer science Category theory is the mathematical study of

configure software and introduce the concepts from category theory that are used in the library. A good way to think of category theory, applied to functional programming, is design patterns. Category theory defines a few low-level abstract concepts. These concepts can be directly expressed in a functional language like Scala and

constructor and a separate configuration can be used to wire all the pieces together using functions. This is an ideal blend of object orientation and functional programming in Scala. For example, if the DataStore trait had an implementation that used a single JDBC connection like the following: class ConnectionDataStore(conn: java.

Config. Applicative style is usually used at the interface between raw types like String and wrapped types like Option[String]. Another common use case in functional programming is creating reusable workflows. 11.4. Monads as workflows A monadic workflow is a pipeline of computation that remains embedded inside the monad. The monad

staged monadic behavior in Scala, this remains a valid reason to encode sequences of operations into monadic workflows. 11.5. Summary Functional programming has a lot to offer the object-oriented developer. Functional programming offers powerful ways to interact with functions. This can be done through applicative style, such as configuring an application, or

advanced abstractions than those we presented here, but it’s well worth a look. Scala provides the tools needed to blend the object-oriented and functional programming worlds. Scala is at its best when these two evenly share a codebase. The biggest danger to misusing Scala is to ignore its object orientation

or its functional programming. But combining the two is the sweet spot that the language was designed to fulfill. Index [SYMBOL][A][B][C][D][E][F][G][

Byte type C C parameter C.super C++ variables Callback type CanBuildFrom class canEqual method case statements, 2nd, 3rd Cat type, 2nd Category Theory and functional programming functors, 2nd monads, 2nd morphism cc target chaining implicits, 2nd changePassword method Child class children method, 2nd class arguments ClassCastExceptions ClassManifest, 2nd closeResource method code

GenSeq GenTraversableOnce get method, 2nd, 3rd, 4th getConnection function getFoo getLines method getNextChild method getOrElse method getstatic operation getTemporaryDirectory method getValue Google Collections, concepts of functional programming in H Handle type, 2nd, 3rd handleMessage method hashCode method, 2nd HashMaps, 2nd HashSet HasLogger hasNext method HCons class, 2nd head method, 2nd, 3rd

9.4. Failure zones for scatter-gather example Figure 9.5. Scatter-gather scheduling zones Figure 9.6. Topology state change Chapter 11. Patterns in functional programming Figure 11.1. Functor transforming types and functions List of Tables Chapter 1. Scala—a blended language Table 1.1. Attributes commonly ascribed to object

-oriented and functional programming Table 1.2. Variable definition in C++ versus Scala Chapter 3. Modicum of style—coding conventions Table 3.1. Coding style examples Chapter 4.

gather tree Chapter 10. Integrating Scala with Java Listing 10.1. The add2 method Listing 10.2. Parcelable Address for Android Chapter 11. Patterns in functional programming Listing 11.1. Functor typeclass Listing 11.2. Monad typeclass Listing 11.3. Applicative typeclass Listing 11.4. Configuring an application using the Config class

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library

by Scott Meyers  · 16 Jun 2001  · 474pp  · 91,222 words

Erlang Programming

by Francesco Cesarini  · 496pp  · 70,263 words

Pragmatic.Programming.Erlang.Jul.2007

by Unknown

Python Web Development With Django

by Jeff Forcier

The Art of R Programming

by Norman Matloff  · 404pp  · 43,442 words

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann  · 17 Apr 2017

Programming Scala

by Unknown  · 2 Jan 2010  · 448pp  · 71,301 words

Scala in Action

by Nilanjan Raychaudhuri  · 27 Mar 2012

The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

by Martin L. Abbott and Michael T. Fisher  · 1 Dec 2009

Python Geospatial Development - Second Edition

by Erik Westra  · 23 May 2013

Programming in Haskell

by Graham Hutton  · 31 Aug 2016

The Singularity Is Near: When Humans Transcend Biology

by Ray Kurzweil  · 14 Jul 2005  · 761pp  · 231,902 words

Programming in Scala

by Martin Odersky, Lex Spoon and Bill Venners  · 15 Jan 2008  · 754pp  · 48,930 words

Programming Scala: tackle multicore complexity on the JVM

by Venkat Subramaniam  · 1 May 2009  · 226pp  · 17,533 words

Natural language processing with Python

by Steven Bird, Ewan Klein and Edward Loper  · 15 Dec 2009  · 504pp  · 89,238 words

Python Data Analytics: With Pandas, NumPy, and Matplotlib

by Fabio Nelli  · 27 Sep 2018  · 688pp  · 107,867 words

Ruby by example: concepts and code

by Kevin C. Baird  · 1 Jun 2007  · 309pp  · 65,118 words

Higher-Order Perl: A Guide to Program Transformation

by Mark Jason Dominus  · 14 Mar 2005  · 525pp  · 149,886 words

Python for Finance

by Yuxing Yan  · 24 Apr 2014  · 408pp  · 85,118 words

Purely Functional Data Structures

by Chris Okasaki  · 12 Apr 1998  · 230pp

Mastering Ethereum: Building Smart Contracts and DApps

by Andreas M. Antonopoulos and Gavin Wood Ph. D.  · 23 Dec 2018  · 960pp  · 125,049 words

Software Design for Flexibility

by Chris Hanson and Gerald Sussman  · 17 Feb 2021

Learn You a Haskell for Great Good!: A Beginner's Guide

by Miran Lipovaca  · 17 Apr 2011  · 559pp  · 130,949 words

Text Analytics With Python: A Practical Real-World Approach to Gaining Actionable Insights From Your Data

by Dipanjan Sarkar  · 1 Dec 2016

Real World Haskell

by Bryan O'Sullivan, John Goerzen, Donald Stewart and Donald Bruce Stewart  · 2 Dec 2008  · 1,065pp  · 229,099 words

Programming in Haskell

by Graham Hutton  · 5 Feb 2007  · 184pp  · 13,957 words

Eloquent JavaScript: A Modern Introduction to Programming

by Marijn Haverbeke  · 15 Nov 2018  · 560pp  · 135,629 words

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software

by Scott Rosenberg  · 2 Jan 2006  · 394pp  · 118,929 words

The Rust Programming Language

by Steve Klabnik and Carol Nichols  · 14 Jun 2018  · 821pp  · 178,631 words

Programming Rust: Fast, Safe Systems Development

by Jim Blandy and Jason Orendorff  · 21 Nov 2017  · 1,331pp  · 183,137 words

Haskell Programming: From First Principles

by Christopher Allen and Julie Moronuki  · 1 Jan 2015  · 1,076pp  · 67,364 words

The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2

by Thomas A. Limoncelli, Strata R. Chalup and Christina J. Hogan  · 27 Aug 2014  · 757pp  · 193,541 words

Algorithms in C++ Part 5: Graph Algorithms

by Robert Sedgewick  · 2 Jan 1992

More Joel on Software

by Joel Spolsky  · 25 Jun 2008  · 292pp  · 81,699 words

Think OCaml

by Nicholas Monje, Allen Downey

Practical OCaml

by Joshua B. Smith  · 30 Sep 2006

The Architecture of Open Source Applications

by Amy Brown and Greg Wilson  · 24 May 2011  · 834pp  · 180,700 words

Full Stack Web Development With Backbone.js

by Patrick Mulder  · 18 Jun 2014  · 190pp  · 52,865 words

Exploring ES6 - Upgrade to the next version of JavaScript

by Axel Rauschmayer  · 3 Oct 2015

Practical C Programming, 3rd Edition

by Steve Oualline  · 15 Nov 2011  · 544pp  · 96,029 words

ANSI Common LISP

by Paul Graham  · 12 Nov 1995  · 450pp  · 569 words

Concepts, Techniques, and Models of Computer Programming

by Peter Van-Roy and Seif Haridi  · 15 Feb 2004  · 931pp  · 79,142 words

The TypeScript Workshop: A Practical Guide to Confident, Effective TypeScript Programming

by Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matthew Thomas Morgan and Wekoslav Stefanovski  · 28 Jul 2021  · 739pp  · 174,990 words

Programming TypeScript

by Boris Cherny  · 16 Apr 2019  · 629pp  · 83,362 words

Monadic Design Patterns for the Web

by L.G. Meredith  · 214pp  · 14,382 words

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann  · 16 Mar 2017  · 1,237pp  · 227,370 words

Python for Data Analysis

by Wes McKinney  · 30 Dec 2011  · 752pp  · 131,533 words

Reactive Messaging Patterns With the Actor Model: Applications and Integration in Scala and Akka

by Vaughn Vernon  · 16 Aug 2015

HBase: The Definitive Guide

by Lars George  · 29 Aug 2011

Introducing Elixir

by Simon St.Laurent and J. David Eisenberg  · 20 Dec 2016

The Stack: On Software and Sovereignty

by Benjamin H. Bratton  · 19 Feb 2016  · 903pp  · 235,753 words

The Art of Monitoring

by James Turnbull  · 1 Dec 2014  · 514pp  · 111,012 words

PostGIS in Action, 2nd Edition

by Regina O. Obe and Leo S. Hsu  · 2 May 2015

Vue.js 2 Cookbook

by Andrea Passaglia  · 27 Apr 2017  · 550pp  · 84,515 words

Learn Python the Hard Way

by Zed Shaw  · 1 Jan 2010  · 249pp  · 45,639 words

Numpy Beginner's Guide - Third Edition

by Ivan Idris  · 23 Jun 2015  · 681pp  · 64,159 words

Advances in Artificial General Intelligence: Concepts, Architectures and Algorithms: Proceedings of the Agi Workshop 2006

by Ben Goertzel and Pei Wang  · 1 Jan 2007  · 303pp  · 67,891 words

The Age of Spiritual Machines: When Computers Exceed Human Intelligence

by Ray Kurzweil  · 31 Dec 1998  · 696pp  · 143,736 words

Python for Unix and Linux System Administration

by Noah Gift and Jeremy M. Jones  · 29 Jun 2009  · 603pp  · 141,814 words

Programming HTML5 Applications

by Zachary Kessin  · 9 May 2011  · 210pp  · 42,271 words

Modern Vim: Craft Your Development Environment With Vim 8 and Neovim

by Drew Neil  · 2 May 2018  · 241pp  · 43,252 words

Bad Data Handbook

by Q. Ethan McCallum  · 14 Nov 2012  · 398pp  · 86,855 words

Developing Web Applications with Haskell and Yesod

by Michael Snoyman  · 22 Apr 2012  · 485pp  · 74,211 words

The C++ Programming Language

by Bjarne Stroustrup  · 2 Jan 1986  · 923pp  · 516,602 words

The Trade Lifecycle: Behind the Scenes of the Trading Process (The Wiley Finance Series)

by Robert P. Baker  · 4 Oct 2015

Coders at Work

by Peter Seibel  · 22 Jun 2009  · 1,201pp  · 233,519 words

JavaScript: the good parts

by Douglas Crockford  · 15 Nov 2008  · 273pp  · 46,214 words

Structure and interpretation of computer programs

by Harold Abelson, Gerald Jay Sussman and Julie Sussman  · 25 Jul 1996  · 893pp  · 199,542 words

Managing Projects With GNU Make

by Robert Mecklenburg and Andrew Oram  · 19 Nov 2004  · 471pp  · 94,519 words

JavaScript & jQuery: The Missing Manual

by David Sawyer McFarland  · 28 Oct 2011  · 924pp  · 196,343 words

Terraform: Up and Running: Writing Infrastructure as Code

by Yevgeniy Brikman  · 13 Mar 2017

Elixir in Action

by Saša Jurić  · 30 Jan 2019

C++ Concurrency in Action: Practical Multithreading

by Anthony Williams  · 1 Jan 2009  · 818pp  · 153,952 words

Programming Clojure

by Stuart Halloway and Aaron Bedra  · 17 Apr 2012  · 536pp  · 73,482 words

Programming Collective Intelligence

by Toby Segaran  · 17 Dec 2008  · 519pp  · 102,669 words

Clojure Programming

by Chas Emerick, Brian Carper and Christophe Grand  · 15 Aug 2011  · 999pp  · 194,942 words

Hadoop: The Definitive Guide

by Tom White  · 29 May 2009  · 933pp  · 205,691 words

Types and Programming Languages

by Benjamin C. Pierce  · 4 Jan 2002  · 647pp  · 43,757 words

The Joy of Clojure

by Michael Fogus and Chris Houser  · 28 Nov 2010  · 706pp  · 120,784 words

Pearls of Functional Algorithm Design

by Richard Bird  · 15 Sep 2010

The Haskell Road to Logic, Maths and Programming

by Kees Doets, Jan van Eijck and Jan Eijck  · 15 Jan 2004

Structure and Interpretation of Computer Programs, Second Edition

by Harold Abelson, Gerald Jay Sussman and Julie Sussman  · 1 Jan 1984  · 1,387pp  · 202,295 words

RDF Database Systems: Triples Storage and SPARQL Query Processing

by Olivier Cure and Guillaume Blin  · 10 Dec 2014

Data and the City

by Rob Kitchin,Tracey P. Lauriault,Gavin McArdle  · 2 Aug 2017

Working Effectively With Legacy Code

by Michael Feathers  · 14 Jul 2004  · 508pp  · 120,339 words

Gnuplot Cookbook

by Lee Phillips  · 15 Feb 2012  · 199pp  · 47,154 words

Learning Node.js: A Hands-On Guide to Building Web Applications in JavaScript

by Marc Wandschneider  · 18 Jun 2013

97 Things Every Programmer Should Know

by Kevlin Henney  · 5 Feb 2010  · 292pp  · 62,575 words

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design

by Diomidis Spinellis and Georgios Gousios  · 30 Dec 2008  · 680pp  · 157,865 words

Speaking JavaScript: An In-Depth Guide for Programmers

by Axel Rauschmayer  · 25 Feb 2014  · 692pp  · 95,244 words

Programming in Lua, Fourth Edition

by Roberto Ierusalimschy  · 14 Jul 2016  · 489pp  · 117,470 words

The Rust Programming Language, 2nd Edition

by Steve Klabnik and Carol Nichols  · 27 Feb 2023  · 648pp  · 183,275 words

Python Tricks: The Book

by Dan Bader  · 14 Oct 2017  · 262pp  · 60,248 words

Tcl/Tk in a Nutshell

by Paul Raines and Jeff Tranter  · 25 Mar 1999  · 1,064pp  · 114,771 words

An Elegant Puzzle: Systems of Engineering Management

by Will Larson  · 19 May 2019  · 227pp  · 63,186 words

The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise

by Nathan L. Ensmenger  · 31 Jul 2010  · 429pp  · 114,726 words

Financial Modelling in Python

by Shayne Fletcher and Christopher Gardner  · 3 Aug 2009  · 246pp  · 16,997 words

Attack of the 50 Foot Blockchain: Bitcoin, Blockchain, Ethereum & Smart Contracts

by David Gerard  · 23 Jul 2017  · 309pp  · 54,839 words

ClojureScript: Up and Running

by Stuart Sierra and Luke Vanderhart  · 24 Oct 2012  · 135pp  · 31,098 words

CTOs at Work

by Scott Donaldson, Stanley Siegel and Gary Donaldson  · 13 Jan 2012  · 458pp  · 135,206 words

Geek Sublime: The Beauty of Code, the Code of Beauty

by Vikram Chandra  · 7 Nov 2013  · 239pp  · 64,812 words

Apache Solr 3 Enterprise Search Server

by Unknown  · 13 Jan 2012  · 470pp  · 109,589 words

JQuery Pocket Reference

by David Flanagan  · 15 Dec 2010  · 211pp  · 37,094 words

Philosophy of Software Design

by John Ousterhout  · 28 Jan 2018  · 211pp  · 58,677 words

Bullshit Jobs: A Theory

by David Graeber  · 14 May 2018  · 385pp  · 123,168 words

Software Engineering at Google: Lessons Learned From Programming Over Time

by Titus Winters, Tom Manshreck and Hyrum Wright  · 17 Mar 2020  · 214pp  · 31,751 words

Racing the Beam: The Atari Video Computer System

by Nick Montfort and Ian Bogost  · 9 Jan 2009

PostGIS in Action

by Regina O. Obe and Leo S. Hsu  · 2 May 2015

Solr in Action

by Trey Grainger and Timothy Potter  · 14 Sep 2014  · 1,085pp  · 219,144 words

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent

by Joel Spolsky  · 1 Jun 2007  · 194pp  · 36,223 words

Principles of Protocol Design

by Robin Sharp  · 13 Feb 2008

Architecting Modern Data Platforms: A Guide to Enterprise Hadoop at Scale

by Jan Kunigk, Ian Buss, Paul Wilkinson and Lars George  · 8 Jan 2019  · 1,409pp  · 205,237 words

Tackling TypeScript

by Dr. Axel Rauschmayer  · 14 Apr 2020

Microsoft Office Outlook 2010 QuickSteps

by Malestrom

I, Warbot: The Dawn of Artificially Intelligent Conflict

by Kenneth Payne  · 16 Jun 2021  · 339pp  · 92,785 words

Network Security Through Data Analysis: Building Situational Awareness

by Michael S Collins  · 23 Feb 2014  · 446pp  · 102,421 words

The Boy Who Could Change the World: The Writings of Aaron Swartz

by Aaron Swartz and Lawrence Lessig  · 5 Jan 2016  · 377pp  · 110,427 words

Uncanny Valley: A Memoir

by Anna Wiener  · 14 Jan 2020  · 237pp  · 74,109 words

Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business

by Arvid Kahl  · 24 Jun 2020  · 461pp  · 106,027 words

Big Data Glossary

by Pete Warden  · 20 Sep 2011  · 58pp  · 12,386 words

The Perfect House: A Journey With Renaissance Master Andrea Palladio

by Witold Rybczynski  · 2 Sep 2002  · 317pp  · 76,169 words