Array-oriented Programming (AoP) dates back to 1960s.The fundamental idea behind AoP is that operations apply at once to an entire set of values. This allows the programmer to think and operate on whole aggregates of data, without having to resort to explicit loops of individual scalar operations. At, a platform for organising and managing technical conferences/events, we've been heavily influenced by the APL style of AoP. In our context, this means each function focuses on applying one transformation to an immutable array (ordered-map) and then spitting out a new array, which can be piped to another function thus achieving functional composition. This has allowed us to build a very modular, decoupled design, which is extremely simple to reason about. 

If you think of typical web-apps, they are generally CRUD applications. Data comes in, you apply a set of transformation and you pass it to someone else via an API or you save/query a data store. And on the way out, you get data from somewhere (data-store, API, etc.), apply a set of transformations and render the transformed data as HTML or JSON. Now we can visualise most web-apps using standard Pipe-and-Filter Architecture. With this, applying some of the functional programming concepts becomes more intuitive.

At, we use the standard LAMP stack. We've used PHP's philosophy of shared-nothing-architecture to address concurrency and scalability concerns. PHP itself has all the basic ingredients required for Functional Programming - first-class, higher-order functions, lambda, closures, partial functions, recursion and so on. We use array (ordered-map) to hold the data. PHP provides 79 array functions that allows you to do pretty much everything you need to in terms of transforming arrays including map, reduce, filter, merge and so on. One needs to be careful, but most of these are pure, higher-order functions. 

If you are interested to learn more about AoP, I'll give a walk through of our design. Also I'll take a couple of problems to explain how to think in terms of AoP and how its really helps with functional programming.

1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • 15 Mins - Design Walk though of (Pipe-and-Filter architecture)
  • 10 Mins - Rendering a multi-day conference schedule using AoP without looping
  • 10 Mins - Credit card validation using AoP without any conditional logic
  • 10 Mins - Wrap up and Q & A

Learning Outcome

  • How to solve real-world problems using AoP thinking
  • How to use AoP such that your data structure can act as a "control structure" and hence avoid conditional logic
  • Why AoP takes you on the functional programming path faster before you delve into category theory
  • Practical application of AoP to solve real-world problems

Target Audience

Developers interested in a fresh perspective of FP

schedule Submitted 2 months ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Manuel Chakravarty

    Haskell SpriteKit - a Purely Functional API for a Stateful Animation System and Physics Engine

    Manuel Chakravarty
    Manuel Chakravarty
    schedule 2 weeks ago
    Sold Out!
    45 mins

    Graphics, animation, and games programming in Haskell faces a dilemma. We can either use existing frameworks with their highly imperative APIs (such as OpenGL, Cocos2D, or SpriteKit) or we waste a lot of energy trying to re-engineer those rather complex systems from scratch. Or, maybe, we can escape the dilemma. Instead of a Haskell program directly manipulating the mutable object-graph of existing high-level frameworks, we provide an API for purely functional transformations of a Haskell data structure, together with an adaptation layer that transcribes those transformations into edits of the mutable object-graph.

    I this talk, I will explain how I used this approach to architect a Haskell binding to the animation system and physics engine of Apple’s SpriteKit framework. I will discuss both how the binding is structured and how it achieves the translation of Haskell side changes to SpriteKit and vice versa, such that it is sufficiently efficient. Moreover, I will demonstrate by example how to use the Haskell library to implement a simple game.

  • Liked Aloïs Cochard

    The Tale of Troy

    Aloïs Cochard
    Aloïs Cochard
    schedule 2 weeks ago
    Sold Out!
    45 mins

    In recent years, the impact of functional programming on mainstream languages has grown significantly.

    After conquering server applications and distributed systems,
    the paradigm is now conquering the fields of web development and data analytics.

    So what remains? The land of system programming.

    When Mozilla did release the language Rust in 2012,
    it did immediately striked interest from functional programming enthusiasts due to it's strong emphasis on safety.

    Even though it currently lacks some advanced features like higher kinded types,
    it is built with functional programming principles as it's core.

    Like a Trojan horse (or the parasite mushroom after the language is named),
    Rust looks like the next C on the outside... while it might actually be closer to Haskell on the inside!

    Let's take a tour and discover an other side of system programming by learning together how to do functional programming in Rust.

  • Calascibetta Romain
    Calascibetta Romain
    schedule 4 days ago
    Sold Out!
    45 mins

    Git is one of the most popular tool for a developper and a part of the power of Git is come from some functional concepts. So, it's obvious to implement the Git format with OCaml!

    This talk will present the functionnal concepts of Git (like the immutable tree) and show a practical implementation with OCaml step by step. Then, we will explain how can scale an OCaml code to compute a huge Git repository and understand by this way the power of OCaml (and the mix between the functionnal and the imperative way).

    At the end, we will show an example of the usability of Git with OCaml with a concrete application.

  • Liked Ravi Mohan

    Predator: A Framework for developing programmatic players for Complex Board Games( in Erlang and PureScript)

    Ravi Mohan
    Ravi Mohan
    schedule 1 week ago
    Sold Out!
    45 mins
    Experience Report

    Summary: An Experience Report on How I'm using Erlang and PureScript to create programmatic opponents aka 'bots' for complex boardgames I love to play but I can't find people to play with!

    The number of boardgames that you can whip out at a gathering and expect people to want play is very small.. Monopoly, Snakes and Ladders, perhaps Settlers of Catan. And that's about it.
    Getting people to play these games is relatively easy.

    However the world of boardgames is *much* wider. There are literally tens of thousands of boardgames that simulate everything from very abstract geometry puzzles to ones thatcomplex economies and political situations. Some of the latter are used in very unexpected ways, e.g to train spies and military officers.

    Here is an example

    A Distant Plain (by GMT Games) is a boardgame for 4 players that put them in the roles of the US military forces, the Afghan government, the Taliban, and Warlords cum drug dealers, all competing for power in Afghanistan.



    Here is another
    The War of the Ring, a game for 2 players.

    "In War of the Ring, one player takes control of the Free Peoples (FP), the other player controls Shadow Armies (SA). Initially, the Free People Nations are reluctant to take arms against Sauron, so they must be attacked by Sauron or persuaded by Gandalf or other Companions, before they start to fight properly ...."


    And one more

    "A game of Eclipse places you in control of a vast interstellar civilization, competing for success with its rivals. You will explore new star systems, research technologies, and build spaceships with which to wage war. There are many potential paths to victory, so you need to plan your strategy according to the strengths and weaknesses of your species, while paying attention to the other civilizations' endeavors."


    What these games have in common
    1. They are wonderful wonderful games, immersing you into their respective worlds.
    2. They have (relative to Snakes and Ladders or Monopoly) complex rulesets.
    3. They are rarely played in India.
    4. Even when people own them, opponents are almost impossible to find and schedule.

    Which means that if you own these games and live in India, getting to actually play these games is close to impossible. Which is a problem.

    Being a programmer, I solve this problem by writing programmatic opponents (aka 'bots') to take the place of other players. This involves all kinds of interesting sub problems - game representation, logic processing for rules, building AI 'smarts' for your opponents, gui and event handling etc.

    Since I am doing this in my non existent spare time, I use time and effort saving languages, aka functional languages, in my case Erlang (originally Haskell) for the backend and PureScript for the front end.

    This talk is about the many challenges I faced in building automated game players (and extracting common frameworks/libraries) from them. Since this is an experience report, it is basically a list  of lessons learned, victories *and defeats*, what worked *and what didn't work*.

    If you can't use FP at work, but are considering doing so on a personal project, or want to learn how to get going on a non-toy FP learning effort, you could benefit from my mistakes and successes.