The Pragmatic Haskeller – Episode 1 by Alfredo Di Napoli.
The first episode of “The Pragmatic Haskeller” starts with:
In the beginning was XML, and then JSON.
When I read that sort of thing, it is hard to know whether to weep or pitch a fit.
Neither one is terribly productive but if you are interested in the rich heritage that XML relies upon drop me a line.
The first lesson is a flying start on Haskell data and moving it between JSON and XML fomats.
“Functional Programming for optimization problems in Big Data” by Paco Nathan.
Interesting slide deck, even if it doesn’t start with high drama. 😉
Covers:
The reading list mentioned in these slides makes a nice self-review course in data science.
The Open Data Example is for Palo Alto but you can substitute a city with open data closer to home.
Purely Functional Data Structures in Clojure: Leftist Heaps by Leonardo Borges.
From the post:
Last year I started reading a book called Purely Functional Data Structures. It’s a fascinating book and if you’ve ever wondered how Clojure’s persistent data structures work, it’s mandatory reading.
However, all code samples in the book are written in ML – with Haskell versions in the end of the book. This means I got stuck in Chapter 3, where the ML snippets start.
I had no clue about Haskell’s – much less ML’s! – syntax and I was finding it very difficult to follow along. What I did notice is that their syntaxes are not so different from each other.
So I put the book down and read Learn You a Haskell For Great Good! with the hopes that learning more about haskell’s syntax – in particular, learning how to read its type signatures – would help me get going with Puretly Functional Data Structures.
Luckily, I was right – and I recommend you do the same if you’re not familiar with either of those languages. Learn You a Haskell For Great Good! is a great book and I got a lot out of it. My series on Monads is a product of reading it.
Enough background though.
The purpose of this post is two-fold: One is to share the github repository I created and that will contain the Clojure versions of the data structures in the book as well as most solutions to the exercises – or at least as many as my time-poor life allows me to implement.
The other is to walk you through some of the code and get a discussion going. Hopefully we will all learn something – as I certainly have when implementing these. Today, we’ll start with Leftist Heaps.
This sounds like a wonderful resource in the making!
I first saw this at Christophe Lalanne’s A bag of tweets / February 2013.
When All The Program’s A Graph – Prismatic’s Plumbing Library
From the post:
At some point as a programmer you might have the insight/fear that all programming is just doing stuff to other stuff.
Then you may observe after coding the same stuff over again that stuff in a program often takes the form of interacting patterns of flows.
Then you may think hey, a program isn’t only useful for coding datastructures, but a program is a kind of datastructure and that with a meta level jump you could program a program in terms of flows over data and flow over other flows.
That’s the kind of stuff Prismatic is making available in the Graph extension to their plumbing package (code examples), which is described in an excellent post: Graph: Abstractions for Structured Computation.
Formalizing the structure of FP code. Who could argue with that?
Read the first post as a quick introduction to the second.
Distributed resilience with functional programming by Simon St. Laurent.
From the post:
Functional programming has a long and distinguished heritage of great work — that was only used by a small group of programmers. In a world dominated by individual computers running single processors, the extra cost of thinking functionally limited its appeal. Lately, as more projects require distributed systems that must always be available, functional programming approaches suddenly look a lot more appealing.
Steve Vinoski, an architect at Basho Technologies, has been working with distributed systems and complex projects for a long time, first as a tentative explorer and then leaping across to Erlang when it seemed right. Seventeen years as a columnist on C, C++, and functional languages have given him a unique viewpoint on how developers and companies are deciding whether and how to take the plunge.
Simon gives highlights from his interview of Steve Vinoski but I would start at the beginning, go to the end, then stop.
You do know that Simon has written an Erlang book? Introducing Erlang.
Haven’t seen it (yet) but knowing Simon you won’t be disappointed.
Hoopl: Dataflow Optimization Made Simple by Norman Ramsey, João Dias, and Simon Peyton Jones.
Abstract:
We present Hoopl, a Haskell library that makes it easy for compiler writers to implement program transformations based on dataflow analyses. The compiler writer must identify (a) logical assertions on which the transformation will be based; (b) a representation of such assertions, which should form a lattice of finite height; (c) transfer functions that approximate weakest preconditions or strongest postconditions over the assertions; and (d) rewrite functions whose soundness is justified by the assertions. Hoopl uses the algorithm of Lerner, Grove, and Chambers (2002), which can compose very simple analyses and transformations in a way that achieves the same precision as complex, handwritten “super-analyses.” Hoopl will be the workhorse of a new back end for the Glasgow Haskell Compiler (version 6.12, forthcoming).
Superceded by later work but recommended by the authors as a fuller introduction to Hoopl.
The superceding work, Hoopl: A Modular, Reusable Library for Dataflow Analysis and Transformation, has the following abstract:
Dataflow analysis and transformation of control-flow graphs is pervasive in optimizing compilers, but it is typically tightly interwoven with the details of a particular compiler. We describe Hoopl, a reusable Haskell library that makes it unusually easy to define new analyses and transformations for any compiler. Hoopl’s interface is modular and polymorphic, and it offers unusually strong static guarantees. The implementation encapsulates state-of-the-art algorithms (interleaved analysis and rewriting, dynamic error isolation), and it cleanly separates their tricky elements so that they can be understood independently.
I started with the later work. Better read in the order presented here.
Daniel Westheide has a series of posts introducing Scala to Neophytes.
As of today:
The Neophyte’s Guide to Scala Part 1: Extractors
The Neophyte’s Guide to Scala Part 2: Extracting Sequences
The Neophyte’s Guide to Scala Part 3: Patterns Everywhere
The Neophyte’s Guide to Scala Part 4: Pattern Matching Anonymous Functions
The Neophyte’s Guide to Scala Part 5: The Option type
The Neophyte’s Guide to Scala Part 6: Error handling with Try
The Neophyte’s Guide to Scala Part 7: The Either type
The Neophyte’s Guide to Scala Part 8: Welcome to the Future
The Neophyte’s Guide to Scala Part 9: Promises and Futures in practice
The Neophyte’s Guide to Scala Part 10: Staying DRY with higher-order functions
Apologies for not seeing this sooner.
Makes a nice starting place for the 25th March 2013 Functional Programming Principles in Scala class by Martin Odersky.
I first saw this at Chris Cundill’s This week in #Scala (26/01/2013).
Functional Programming Principles in Scala by Martin Odersky.
March 25th 2013 (7 weeks long)
From the webpage:
This course introduces the cornerstones of functional programming using the Scala programming language. Functional programming has become more and more popular in recent years because it promotes code that’s safe, concise, and elegant. Furthermore, functional programming makes it easier to write parallel code for today’s and tomorrow’s multiprocessors by replacing mutable variables and loops with powerful ways to define and compose functions.
Scala is a language that fuses functional and object-oriented programming in a practical package. It interoperates seamlessly with Java and its tools. Scala is now used in a rapidly increasing number of open source projects and companies. It provides the core infrastructure for sites such as Twitter, LinkedIn, Foursquare, Tumblr, and Klout.
In this course you will discover the elements of the functional programming style and learn how to apply them usefully in your daily programming tasks. You will also develop a solid foundation for reasoning about functional programs, by touching upon proofs of invariants and the tracing of execution symbolically.
The course is hands on; most units introduce short programs that serve as illustrations of important concepts and invite you to play with them, modifying and improving them. The course is complemented by a series of assignments, most of which are also programming projects.
In case you missed it last time.
I first saw this at Chris Cundill’s This week in #Scala (26/01/2013).
Confluently Persistent Sets and Maps by Olle Liljenzin.
Abstract:
Ordered sets and maps play important roles as index structures in relational data models. When a shared index in a multi-user system is modified concurrently, the current state of the index will diverge into multiple versions containing the local modifications performed in each work flow. The confluent persistence problem arises when versions should be melded in commit and refresh operations so that modifications performed by different users become merged.
Confluently Persistent Sets and Maps are functional binary search trees that support efficient set operations both when operands are disjoint and when they are overlapping. Treap properties with hash values as priorities are maintained and with hash-consing of nodes a unique representation is provided. Non-destructive set merge algorithms that skip inspection of equal subtrees and a conflict detecting meld algorithm based on set merges are presented. The meld algorithm is used in commit and refresh operations. With m modifications in one flow and n items in total, the expected cost of the operations is O(m log(n/m)).
Is this an avenue for coordination between distinct topic maps?
Or is consistency of distinct topic maps an application-based requirement?
Resources for Getting Started With Functional Programming and Scala by Kelsey Innis.
From the post:
This is the “secret slide” from my recent talk Learning Functional Programming without Growing a Neckbeard, with links to the sources I used to put the talk together and some suggestions for ways to get started writing Scala code.
The “…without growing a neckbeard” merits mention even if you are not interested in functional programming and topic maps.
Nice list of resources.
Don’t miss the presentation!
I first saw this at This week in #Scala (11/01/2013) by Chris Cundill.
chemf: A purely functional chemistry toolkit by Stefan Höck and Rainer Riedl. (Journal of Cheminformatics 2012, 4:38 doi:10.1186/1758-2946-4-38)
Abstract:
Background
Although programming in a type-safe and referentially transparent style offers several advantages over working with mutable data structures and side effects, this style of programming has not seen much use in chemistry-related software. Since functional programming languages were designed with referential transparency in mind, these languages offer a lot of support when writing immutable data structures and side-effects free code. We therefore started implementing our own toolkit based on the above programming paradigms in a modern, versatile programming language.
Results
We present our initial results with functional programming in chemistry by first describing an immutable data structure for molecular graphs together with a couple of simple algorithms to calculate basic molecular properties before writing a complete SMILES parser in accordance with the OpenSMILES specification. Along the way we show how to deal with input validation, error handling, bulk operations, and parallelization in a purely functional way. At the end we also analyze and improve our algorithms and data structures in terms of performance and compare it to existing toolkits both object-oriented and purely functional. All code was written in Scala, a modern multi-paradigm programming language with a strong support for functional programming and a highly sophisticated type system.
Conclusions
We have successfully made the first important steps towards a purely functional chemistry toolkit. The data structures and algorithms presented in this article perform well while at the same time they can be safely used in parallelized applications, such as computer aided drug design experiments, without further adjustments. This stands in contrast to existing object-oriented toolkits where thread safety of data structures and algorithms is a deliberate design decision that can be hard to implement. Finally, the level of type-safety achieved by \emph{Scala} highly increased the reliability of our code as well as the productivity of the programmers involved in this project.
Another vote in favor of functional programming as a path to parallel processing.
Can the next step, identity transparency*, be far behind?
*Identity transparency: where any identification of an entity can be replaced with another identification of the same entity.
Watching the What’s New in Cassandra 1.2 (Notes) webcast and encountered an unfamiliar term: “tombstones.”
If you are already familiar with the concept, skip to another post.
If you’re not, the concept is used in distributed systems that maintain “eventual” consistency by the nodes replicating their content. Which works if all nodes are available but what if you delete data and a node is unavailable? When it comes back, the other nodes are “missing” data that needs to be replicated.
From the description at the Cassandra wiki, DistributedDeletes, not an easy problem to solve.
So, Cassandra turns it into a solvable problem.
Deletes are implemented with a special value known as a tombstone. The tombstone is propogated to nodes that missed the initial delete.
Since you will eventually want to delete the tombstones as well, a grace period can be set, which is slightly longer than the period needed to replace a non-responding node.
Distributed topic maps will face the same issue.
Complicated by imperative programming models of merging that make changes in properties that alter merging difficult to manage.
Perhaps functional models of merging, as with other forms of distributed processing, will carry the day.
Rise And Fall Of Computer Languages In 2012 by Andrew Binstock.
From the post:
The most recent processor phenomenon — the transition from the multicore to many-core era — was expected to set the stage for the emergence of functional languages, which fit well with concurrent programming. But most surveys from 2012 still show no major breakthrough. If a functional language does separate from the pack, the leading candidates are Scala and Clojure, with Scala enjoying the greater adoption right now. This per Ohloh’s language figures, which cover all open source projects, and Google trends, which indicate search traffic. On the venerable Tiobe index, which tracks the number of Web pages that mention a given language, Haskell, Erlang, and Scala are effectively tied and ahead of Clojure.
The full story appears at Dr. Dobbs.
Other reasons to prefer functional languages/approaches:
Learn You Some Erlang for Great Good! is now a real book! by Paolo D’Incau.
From the post:
In my humble opinion if you want to learn or improve your Erlang, writing a lot of code is a good idea but is really not enough: you have to learn from other people’s work, you have to read more from blogs and books.
That’s the reason why in one of my oldest posts I recommended you to take a look at 7 Erlang related websites among which you will find the good old http://learnyousomeerlang.com/. I firmly believe that most of Erlangers out there learnt a lot from Fred Heber‘s work; the amount of information he provides is just impressive and his way to teach Erlang by small (well, not that small) examples is the best one I have seen so far online.
BTW, if you read Paolo’s post, you will find a 30% discount code for: Learn You Some Erlang for Great Good!.
Thanks to Paolo, I am now also waiting for my copy to arrive! (Misery loves company.)
Functional Composition by Chris Ford.
From the webpage:
A live-coding presentation on music theory and Bach’s “Canone alla Quarta” by @ctford.
Based on Overtone:
Overtone is an open source audio environment being created to explore musical ideas from synthesis and sampling to instrument building, live-coding and collaborative jamming. We use the SuperCollider synth server as the audio engine, with Clojure being used to develop the APIs and the application. Synthesizers, effects, analyzers and musical generators can be programmed in Clojure.
Come and join the Overtone Google Group if you want to get involved in the project or have any questions about how you can use Overtone to make cool sounds and music.
An inducement to learn Clojure and to better understand the influence of music on the second edition of HyTime.
I first saw this in Christophe Lalanne’s A bag of tweets / November 2012.
DRAKON-Erlang: Visual Functional Programming
DRAKON is a visual programming language developed for the Buran Space Project.
I won’t repeat the surplus of adjectives used to describe DRAKON. Its long term use in the Russian space program is enough to recommend review of its visual techniques.
The DRAKO-Erlang project is an effort to combine DRAKON as a flow language/representation with Erlang.
A graphical notation for topic maps never caught on and with the rise of big data, visual representation of merging algorithms could be quite useful.
I am not suggesting DRAKON-Erlang as a solution to those issues but as a data point to take into account.
Others?
Introductory FP Course Materials by Robert Harper.
First semester introductory programming course.
Second semester data structures and algorithms course.
Deeply awesome body of material.
Enjoy!
Erik Meijer – Functional Programming From First Principles
From the description:
Our favorite iconoclast, Erik Meijer, presented a very interesting talk at a recent GOTO Chicago event, Functional Programming Night. He originally planned on doing his popular “Fundamentalist Functional Programming” talk, but instead decided to address FP from a slightly different angle – “Functional Programming from First Principles”. (Speaking of FP first principles, if you haven’t seen Erik’s FP lecture series, well, you really should!).
Has Erik changed his mind about rampant side effects and imperative programming? What’s going to happen to the poor monkey Rich Hickey made reference to several times in his excellent talk The Database as a Value (which he presented after Erik’s talk)? Is Erik still a functional programming fundamentalist? Watch and decide. As you’d expect, it’s high energy, brilliant Erik all the way.
From near the end:
Functional “Programming” is a tool for thought.
Imperative “Programming” is a tool for hacking.
Deeply entertaining.
Has been posted for 1 day with a reported > 20,986 views. (You can take that as a recommendation.)
Thinking Functionally with Haskell: Types? Tests? We Need a New Word by Paul Callaghan.
From the post:
In which we explore what modern type systems bring to the table.
Imagine an approach to programming where you write down some description of what your code should do, then before running your code you run some automatic tool to see if the code matches the description. That’s Test-driven development, you say!
Actually, this is what you are doing when you use static types in most languages too. Types are a description of the code’s inputs and outputs, and the check ensures that inputs and outputs match up and are used consistently. Modern type systems—such as in Haskell or above—are very flexible, and allow these descriptions to be quite detailed; plus they are not too obtrusive in use and often very helpful.
One point I’ll investigate here is how advances in types are converging with new ideas on testing, to the point where (I claim) the old distinctions are starting to blur and starting to open up exciting new possibilities—hence my suggestion that we need a new word to describe what we’re doing that is free from preconceptions and out-dated thinking.
So put aside your bad experiences from Java, and prepare to be amazed!
I suppose we should all wish Paul luck on finding words that are “…free from preconceptions and out-dated thinking.”;-)
It has been my experience that “new” words replace “[existing] preconceptions and out-dated thinking,” with “[different] preconceptions and out-dated thinking.”
Not a bad thing but let’s be honest that we are contending for different preconceptions and assumptions as opposed to having none at all.
Has the potential to make us less resistant when some (then) younger programming generation wants to overturn “…preconceptions and out-dated thinking.”
If you haven’t kept up with type theory, you should spend some time with Paul’s post. Maybe suggest a new word or two.
Thinking Functionally with Haskell by Paul Callaghan.
From the post:
In which we begin an exploration into the Haskell language and dive deeply into functional programming.
Ever wondered how functional programmers think? I aim to give you a glimpse into the programming style and mindset of experienced functional programmers, so you can see why we are so passionate about what we do. We’ll also discuss some wider ideas about programming, such as making our languages fit the problem and not the other way round, and how this affects language design.
Few of these ideas get the exposure they deserve in textbooks or tutorials, and in my view they are essential for coming to grips with a functional language and using it productively in real apps.
Syntax and semantics, the meat and veg of most books and university courses, are ok for basic language use, but to really master a language that embodies a paradigm that is new to you, you need to know about the deeper pragmatic ideas. Let’s see if we can do something about that.
I used Lisp for a few years before university, then switched to Haskell and have been using it for around 20 years. However, inspired by learning about Rails and Ruby when revamping a tired web technology course, I changed career to do full-time Rails work, and have spent the last four years having fun on a variety of apps, including Spree (#2 committer at one point) and recently a big bespoke lab management system.
Ruby feels like naughty fun for a Haskell programmer. Many of the ideas are very similar, like the very natural use of blocks and lambdas and having lots of scope for bending the rules. I really enjoy programming in Ruby, though some times I do get homesick and pine for a bit more oomph.
Most of this article will refer to Haskell, though many of the ideas do apply to other, similar languages as well. Haskell has a few advantages and a good balance of features. Haskell has its weaknesses too, and I hope to explore these in due course.
I rather like the “…making our languages fit the problem and not the other way round…” phrase.
Or to phrase it for topic maps: “….taking subject identity as defined by users, not defining it for them….”
Perhaps I should ask: Do you want to privilege users or system designers?
Crash Course in Erlang by Knut Hellan.
Knut writes:
This is a summary of a talk I held Monday May 14 2012 at an XP Meetup in Trondheim. It is meant as a teaser for listeners to play with Erlang themselves.
First, some basic concepts. Erlang has a form of constant called atom that is defined on first use. They are typically used as enums or symbols in other languages. Variables in Erlang are [im]mutable so assigning a new value to an existing variable is not allowed. (emphasis added)
Not so much an introduction as a tease to get you to learn more Erlang.
Some typos but look upon those as a challenge to verify what you are reading.
I may copy this post “as is” and use it as a “critical reading/research” assignment for my class.
Then have the students debate their corrections.
That could be a very interesting exercise on not taking everything you read on blind faith, how do you verify what you have read and in the process, evaluate that material as well.
Do you develop a sense of trust for some sources as being “better” than others? Are there ones you turn to by default?
Neal Ford writes:
Some contingents in the functional world claim that the concept of the design pattern is flawed and isn’t needed in functional programming. A case can be made for that view under a narrow definition of pattern — but that’s an argument more about semantics than use. The concept of a design pattern — a named, cataloged solution to a common problem — is alive and well. However, patterns sometimes take different guises under different paradigms. Because the building blocks and approaches to problems are different in the functional world, some of the traditional Gang of Four patterns (see Resources) disappear, while others preserve the problem but solve it radically differently. This installment and the next investigate some traditional design patterns and rethink them in a functional way.
In the functional-programming world, traditional design patterns generally manifest in one of three ways:
- The pattern is absorbed by the language.
- The pattern solution still exists in the functional paradigm, but the implementation details differ.
- The solution is implemented using capabilities other languages or paradigms lack. (For example, many solutions that use metaprogramming are clean and elegant — and they’re not possible in Java.)
I’ll investigate these three cases in turn, starting in this installment with some familiar patterns, most of which are wholly or partially subsumed by modern languages.
Neal continues this series in: Functional thinking: Functional design patterns, Part 2
In the lead-in Neal says:
… patterns sometimes take different guises under different paradigms.
What? Expression of patterns vary from programming language to programming language?
Does that mean if I could trace patterns from one language to another that I might have greater insight into the use of patterns across languages?
Not having to relearn a pattern or its characteristics?
Does that sound like a net win?
If it does, consider topic maps as one path to that net win.
Why Big Data Needs to be Functional by Dean Wampler.
Slides from Dean Wampler’s keynote at NEScala 2012.
I won’t spoil the ending for you so suffice it to say that functional programming is said to be relevant for big data tasks. 😉
Is looking at “big data” as “functional” saying that use of “big data” needs to be pluralistic?
That the cost of acquiring, cleaning, maintaining, etc., “big data” is big (sorry) enough that re-use is a real value?
Such that changing data that has already been gathered, cleaned, reconciled, i.e., imperative processing, is simply unthinkable?
Perhaps read-only access is the new norm, to protect your investment in “big data.”
Functional thinking: Functional design patterns, Part 1 – How patterns manifest in the functional world
Summary
Contrary to popular belief, design patterns exist in functional programming — but they sometimes differ from their object-oriented counterparts in appearance and behavior. In this installment of Functional thinking, Neal Ford looks at ways in which patterns manifest in the functional paradigm, illustrating how the solutions differ.
From the article:
Some contingents in the functional world claim that the concept of the design pattern is flawed and isn’t needed in functional programming. A case can be made for that view under a narrow definition of pattern — but that’s an argument more about semantics than use. The concept of a design pattern — a named, cataloged solution to a common problem — is alive and well. However, patterns sometimes take different guises under different paradigms. Because the building blocks and approaches to problems are different in the functional world, some of the traditional Gang of Four patterns (see Resources) disappear, while others preserve the problem but solve it radically differently. This installment and the next investigate some traditional design patterns and rethink them in a functional way.
A functional approach to topic maps lends a certain elegance to the management of merging questions. 😉
Comments?
Variations for computing results from sequences in Scala
From the post:
A common question from students who are new to Scala is: What is the difference between using the map function on lists, using for expressions and foreach loops? One of the major sources of confusion with regard to this question is that a for expression in Scala in not the equivalent of for loops in languages like Python and Java — instead, the equivalent of for loops is foreach in Scala. This distinction highlights the importance of understanding what it means to return values versus relying on side-effects to perform certain computations. It also helps reinforce some points about fixed versus reassignable variables and immutable versus mutable data structures.
Continuing with the FP theme. Don’t miss the links to additional tutorial materials on Scala at the end of this post.
An invitation to FP for Clojure noobs
From the post:
I’ve heard newcomers to Clojure ask how to get started with functional programming. I believe that learning to program in the functional style is mostly a matter of practice. The newcomer needs to become familiar with a handful of higher order functions, and how they are used in common idioms. This can be done by practice with simple, well defined problems. I assume that the prospective reader already has a grasp of the rudiments of Clojure, and can operate the Leiningen build tool.
Here is what I propose. I have prepared a set of annotated exercises illustrating typical Clojure fp idioms. The exercises are the first 31 Project Euler problems, one for each day of the month. I believe these problems are ideal for the purpose at hand. Each problem is succinctly stated, interesting, and well defined. Each lends itself to a natural functional solution.
Sounds like an interesting approach to learning Clojure.
Would be interesting if processor speed and virtually unlimited storage tips the scales in favor of write-only memory and functional programming.
Where even mis-typed keystrokes are recorded, it being easier to record the next try than to correct the previous one. Will appear in secure facilities first but won’t remain there.
Functional Relational Programming with Cascalog by Stuart Sierra.
From the post:
In 2006, Ben Mosely and Peter Marks published a paper, Out of the Tar Pit, in which they coined the term Functional Relational Programming. “Out of the Tar Pit” was influential on Clojure’s design, particularly its emphasis on immutability and the separation of state from behavior. Mosely and Marks went further, however, in recommending that data be manipulated as relations. Relations are the abstract concept behind tables in a relational database or “facts” in some logic programming systems. Clojure does not enforce a relational model, but Clojure can be used for relational programming. For example, the clojure.set namespace defines relational algebra operations such as project and join.
In the early aughts, Jeffrey Dean and Sanjay Ghemawat developed the MapReduce programming model at Google to optimize the process of ranking web pages. MapReduce works well for I/O-bound problems where the computation on each record is small but the number of records is large. It specifically addresses the performance characteristics of modern commodity hardware, especially “disk is the new tape.”
Stuart briefly traces the development of Cascalog and says it is an implementation of Functional Relational Programming.
What do you think?
Functional Programming with High Performance Actors
From the introduction:
But with current technologies we end up developing programs with an architecture specific to the problem at hand. And re-architect our programs as the requirements change. This is a labor-intensive approach that minimizes code reuse, particularly when using actors and refactoring method calls to be asynchronous messages or asynchronous messages become method calls. To maximize reuse, an actor should neither know nor care if the exchange of messages with another actor is synchronous or asynchronous. And if most message exchanges are synchronous, we can have many small actors working at a fairly low-level without slowing the program down to a crawl.
Another issue is flow control and its impact on throughput. Messaging is typically one-way, and takes extra effort to add flow control. But without some flow control, the systems we develop behave badly under load. Also, if you send one message at a time and do not proceed until a response is received, the throughput of most actor implementations will suffer a severe drop in throughput. What is needed is a messaging system which is more like method calls, while still having a reasonably high throughput rate.
I don’t think there is any doubt that hardware development has greatly out-stripped the ability to software to take full advantage of the additional processing power.
One possible paradigm shift may be extensive use of message passing.
Thoughts on how message passing can be applied to graph processing?
From the post:
Prompted by some recent work I’ve been doing on reasoning about monadic computations, I’ve been looking back at the work from the 1990s by Phil Trinder, Limsoon Wong, Leonidas Fegaras, Torsten Grust, and others, on monad comprehensions as a framework for database queries.
The idea goes back to the adjunction between extension and intension in set theory—you can define a set by its extension, that is by listing its elements:
or by its intension, that is by characterizing those elements:
Expressions in the latter form are called set comprehensions. They inspired a programming notation in the SETL language from NYU, and have become widely known through list comprehensions in languages like Haskell. The structure needed of sets or of lists to make this work is roughly that of a monad, and Phil Wadler showed how to generalize comprehensions to arbitrary monads, which led to the “do” notation in Haskell. Around the same time, Phil Trinder showed that comprehensions make a convenient database query language. The comprehension notation has been extended to cover other important aspects of database queries, particularly aggregation and grouping. Monads and aggregations have very nice algebraic structure, which leads to a useful body of laws to support database query optimization.
If you are interesting in functional programming and/or “database query optimization” you will enjoy this post.
Functional Programming with Python – Part 1 by Dhananjay Nene.
From the post:
Lately there has been a substantial increase in interest and activity in Functional Programming. Functional Programming is sufficiently different from the conventional mainstream programming style called Imperative Programming to warrant some discussion on what it is, before we delve into the specifics of how it can be used in Python.
And why Python? The author answers:
Python is not the best functional programming language. But it was not meant to be. Python is a multi paradigm language. Want to write good old ‘C’ style procedural code? Python will do it for you. C++/Java style object oriented code? Python is at your service as well. Functional Programming ? As this series of posts is about to demonstrate – Python can do a decent job at it as well. Python is probably the most productive language I have worked with (across a variety of different types of programming requirements). Add to that the fact that python is a language thats extremely easy to learn, suffers from excellent readability, has fairly good web frameworks such as django, has excellent mathematical and statistical libraries such as numpy, and cool network oriented frameworks such as twisted. Python may not be the right choice if you want to write 100% FP. But if you want to learn more of FP or use FP techniques along with other paradigms Python’s capabilities are screaming to be heard.
He forgot to mention that more people know Python than any of the various “functional” programming languages. Increases the potential audience for an article on the advantages of functional programming. 😉
Powered by WordPress