The event will be held on February 9 at Teekkarisauna (Tekniikankatu 9, Tampere) from 17:00 onwards. If you love creating things using bleeding edge technology, please contact us with your CV at Sauna@LeonidasOy.fi. Let us know why it makes a difference for you to be invited, and we will get back to you as soon as possible. You may also come and say hi to us in Tietotalo, TUT before the event between 12:00 and 16:00.

Here is the first article:  NFA in a Single Line of Haskell

Sustaining and disruptive innovation

The division of innovation into sustaining or disruptive types comes from Clayton Christensen and his book The Innovator’s Dilemma. In brief, the theory states that incumbent companies constantly build better versions of their existing products. They become experts at serving their core customer base, but are not quite as good at serving new markets. This is called sustaining innovation.

Incumbents are vulnerable to disruptive innovation that can occur when someone else comes up with a whole new value proposal. The new product may be worse in many respects than the incumbent products, but it more directly addresses the needs of its market. Because the makers of the existing products see the market differently, they may not even consider the disruptor a serious competitor at first.

The difference between sustaining and disruptive innovation, thus, relates to the product’s value proposal. In sustaining innovation, the values are the same as those pertaining to the existing products. Disruptive innovation, on the other hand, uncovers a whole new set of values.

A textbook example is how the iPhone became the leading smart phone. Before iPhone, in 2007, smart phones had a rather small market. The most important and valuable features of smart phones were ordinary phone features, along with the ability to write emails and use a calendar. When the iPhone arrived, it was worse than the incumbents in many ways: it had poor sound quality, it dropped calls, it lacked 3G, it didn’t have a physical keyboard, and it was very expensive. So, to the core group of techno-savvy business users, it was not nearly as attractive as the other choices. However, it had certain benefits that made it attractive beyond the traditional core group. It had a user interface that was a delight to use, it acted as an iPod, and it had the best web browser on the market. It was a new kind of smart phone for a new kind of user.

Both disruptive and sustaining innovations have their place. Markets and competition are marked by short bursts of disruptive innovation, followed by long stretches of sustaining innovation before the next disruption. After the disruption in 2007, the smart phone industry has seen four years of sustaining innovation. Practically all current smart phones now look like iPhones, and they are all better than the original iPhone. The competition is about who has the best features and the best specs; that is, who can generate sustaining innovation.

Coming back to our subject, when we create a prototype, the distinction between sustaining and disruptive innovation is important to us. We should know why we are doing it, and what questions need to be answered. This depends heavily on whether our innovation is sustaining or disruptive.

The questions in disruptive innovation

When creating something disruptive, everything is uncertain. We have an idea for a new kind of service or a new kind of customer that we are going to reach with our product. Yet, we don’t know for sure whether the targeted customer has any desire for what we are planning. So, we want to make sure that a market exists for our product.

Examples of questions to ask at this point:

• Would anyone use our product?
• Would anyone pay for our product?
• Would the use of this particular product spread among customers? Would there be enough growth to sustain our business?
• If not this product, then what would make users happy?

Often, the best way to answer these questions is to build a prototype, show it to potential customers, ask the right questions, and listen to their feedback.

Qualitative feedback may be all that is required. You meet a few potential users, and see how they react. The caveat, of course, is that the use of the product during these interviews is not the same as real use. The consumers whose feedback is being solicited may feel the urge to please the interviewer with their answers, so their responses cannot be blindly trusted. Interviewing users is a skill all on its own.

It would be better to obtain quantitative feedback as well. Depending on the target market, it might be a good idea to put the prototype out into the world, market it to potential users (e.g. via search engine text ads), and see how many sign up. This produces a concrete metric for the degree of interest in one’s customer base.

The questions in sustaining innovation

Sustaining innovation is different. You already know the customers and what they value. You want to improve the product you have, or enter the market with a product that is essentially the same as that of the competition, only better in some respects. In any case, you already know two things: what you are comparing your product against, and what aspects you want to improve.

Prototyping has a place in this sort of innovation, too. The improved version has not been built before, and you are unsure whether it performs as well as expected. This uncertainty can be reduced by asking the right questions and then answering them with a prototype.

Some questions you may ask at this point include:

• Would this improvement produce the efficiency benefits that we thought it would?
• Would users choose our product over the competition’s product, based on this feature?
• How often would they use this new feature?

The questions depend very much on the type of improvement at which one is aiming. If a new feature is being created, the questions relate to the use of the feature and its benefits. On the other hand, if you seek to improve the production process, the questions relate more to efficiency, and so on.

Quantitative metrics should be used when answering these questions. For example, with regard to process improvement, you could measure the difference in the use of resources (such as time) compared to the original version. When planning a new feature, an alpha version of the feature could be released to a set of customers in order to assess how they use it.

Qualitative metrics have their use here, too. It may be expensive to build a sufficiently-good prototype to answer questions quantitatively at first. In that case, the qualitative questions should be posed first to decide whether it makes sense to continue along the current path, or to make changes. Then, a better prototype can be built to measure things quantitatively.

Eliminate waste

One way to look at prototyping is that it eliminates waste from the innovation process. At the start of innovation, the most important result of one’s work is information: i.e., whether the current idea works, and whether it can be improved. So, what creates accurate and relevant information is valuable; what does not, is waste.

Instead of paying, and waiting, for an entire product to be completed, the construction of a prototype will help you to answer the questions quickly and effectively. However, it is not enough to build just any prototype. Ask the right questions, and you will eliminate a huge amount of waste. It is important to know whether your innovation is sustaining or disruptive. The questions are different, and the prototype will differ accordingly.

The division between sustaining and disruptive innovation is just one factor that can alter the questions to be answered. It takes skill and experience to know what the right questions are, and to build a prototype that best addresses those questions. We can help you.

One of the sessions we most looked forward to was Jeff Casimir’s talk entitled “Blow Up Your Views.”  He called for a better separation of views and business logic. We had already been going in that direction in our projects: minimizing data transfer to a plain template and JSON while letting the browser do the rendering. Jeff’s presentation entertained us quite a bit and merged well with our view of how web software should work.

Are developers also designers? Developers should have at least a basic knowledge of design to avoid pitfalls because software is valuable only if it is usable. Jarkko Laine’s talk entitled “Full Frontal for the Backend Pack” was a reminder of the importance of interaction design in web apps. One of the things he talked about was using HTML5’s History API to maintain linearity in browsing, which is exactly what we have been doing when moving a rendering to the client side.

We were excited to hear Zach Holman talking about maintaining flow at GitHub. They avoid metawork, work asynchronously via Git, and use a simple branching strategy similar to ours. But above all, they love great software and creating it, as do we. We don’t go as far as communicating with pull requests to avoid interruptions, but we do have the ticking of a Pomodoro timer to indicate flow. Some parts of the GitHub method probably work well only when you are developing something like GitHub though.

The guys at GitHub presented another session towards the end of the conference, and Aman Gupta gave the most information-packed talk of the conference about debugging performance issues in Ruby. In a little less than an hour, he introduced us to a dozen tools, providing brief explanations and use cases. Obviously, we didn’t have enough time to learn everything there is to know about the topic, but he gave us a good idea of what tools will be handy and where to look for them.

It was nice to note the feeling of connection and unity within the Rails and Open Source community. The atmosphere felt very casual, and it was easy to strike up a conversation with just about anyone. We returned to Tampere feeling invigorated and excited.

1. You think you should add memory to your laptop to make Scala development on Eclipse less painful. Who should you ask to order it?
2. A customer wants a new feature, but you think the feature is useless. On the other hand, it is a big feature and would let you bill the customer for two additional months. What should you do?
3. You’ve played with Clojure during your free time, but never used it in a project. A new project is starting, and Clojure sounds like a good choice for it. Should you use it?

Pose these questions to different people and you will get very different answers. In Leonidas, though, most people, if not everyone, would answer along these lines:

1. Just order the memory yourself with your company credit card.
2. Talk with the customer about the feature. Try to understand his point of view better, and explain why you don’t see value in the feature. Let him know it is important to understand exactly why the feature is needed, so you can do a good job on it.
3. It depends on the details, but you should definitely not be afraid to try Clojure if you think the company would learn something useful from it.

If you work at Leonidas, we want you to make these kinds of decisions on your own or within your team. You do not need to ask your boss for permission (in fact, we do not want there to be that many bosses either). On the other hand, we want there to be common answers so that you feel you are safe to make choices and so everyone has an idea of how the company works in general.

The point of values is to remove barriers from decision making. Leaders make sure that values are understood, respected, and followed; not direct and tell how the actual work should be done.

That is why we make a fuss about values. We talk about them often. If something surprising happens or something did not go as well as we hoped, we ask, “Did we follow our values?” If there is a big disagreement over something, we ask “How does this decision mesh with our values?” And to remind ourselves about our values before anything like that happens, we ask “How did the values manifest themselves last week?”

Leonidas has three values: trust, candor, and kaizen.

Trust means you let other people do their work and do not micromanage. The company needs trust to work productively and creatively. Ordering the laptop memory by yourself is an example of trust. Others trust you to make the right decision and not abuse the power.

The other side of trust is that you can be vulnerable, without fear of ridicule. We understand that everyone is human and everyone makes mistakes. When you are open to the fact that you do not need to be perfect, you are open to honest communication and actual improvement.

Candor means sharing your thoughts. It is more complicated than just saying whatever you are thinking; your goal is to make the other person understand what you are saying. The answer to the second question above is an example of using candor: You tell the customer of your doubts, even when remaining silent about how it would benefit our company in the short run.

Kaizen is Japanese for continuous improvement. It means we will always be looking for new ways to improve all layers of the organization. For example, we often speak of “making the wow” when we present the results of our Protosonni. Kaizen means we are not happy with “the ordinary wow”—we want to wow ourselves in addition to the customer. The hypothetical usage of Clojure is an example of kaizen: Learning new things is valuable to us; therefore, we try out new things.

Our values form a kind of cascade. With trust, you can be candid, speak your mind, and know that others will not hang you if you happen to say something wrong. Trust and candor enable kaizen: When we are able to talk about anything, hard issues can be touched and improved.

Everyone enjoys their work more when they have the control over it. Shared values let us give control to where it belongs.

Abstractions are difficult to communicate

Every product development project starts with an idea. Someone perceives a need and then imagines a solution that resolves this need. Sometimes this idea is correct from the start, and sometimes it needs refinement. But every time, it needs to be communicated – first inside and then outside the organization.

As ideas are abstract, they are not easy to communicate. This is especially the case if they truly contain a “new”, “unheard of” or “revolutionary” component. Nevertheless, successful communication is crucial. If we communicate ineffectively, bad things happen:

• We waste our most valuable resource – time
• We waste our second most valuable resource – energy
• We make bad decisions based on wrong perceptions

Variance in individual perceptions and experiences

Now, in order to for us to understand each other, we should define two terms – perception and experience. In this post, I use the term perception to refer to the process of attaining understanding of a concept by organizing and interpreting sensory information. By the term experience, I mean a state or a series of states that are formed in the mind as a result of conscious or unconscious processes, such as thought, perception, memory, emotion and imagination. So, in plain English, we create experiences through perception.

We perceive the world through our senses, namely sight, hearing, taste, touch and smell. Dedicated sensory cells in our bodies receive signals from our environment and direct them to our brains for interpretation. Now, this is where things get a bit complicated. Even if you and I can both see the color blue, my notion of blue will not be your notion of blue. Our brains interpret, that is perceive, the same signal in different ways depending on our unique physique and mental processes. Thus, our experiences will differ.

When you think about a car, what do you see? A parent might see a family car. A rich poker player may see a sports car, such as a Ferrari or a Lamborghini. And what about the details? What is the color of the car, its size, its interior?

We understand that the word “car” can be interpreted in a great number of ways by different people. Therefore, the variance of individual experience for this concept, “car,” is high.

When a concept is new to us, by definition, we don’t have any previous experience with it. Therefore, our perceptions of the concept stem from our associations with previous, unrelated, experiences. Because these associations vary, we have no way of knowing if we are thinking of the same concept as long as we’re communicating it via language alone.

We need to understand that we all perceive the world in our own unique way.

This variance in experience creates problems. The problem is not that we perceive and therefore experience things differently; in fact, I consider that richness in diversity to be a tremendous resource in human beings. The problem arises when we assume that we’re talking about the same thing when we’re not. This assumption, first of all, it makes alignment of resources difficult. For example, if I say, “Make a vehicle,” and the motor expert in my team starts to build a motor for a car and the frame expert in my team builds a frame for an armored vehicle, then we are probably not going the get a scooter, which is what I had in mind. In order to align resources, we must be able to communicate clearly the particulars of our ideas, thus unifying our vision.

Variance in experience makes alignment of resources difficult.

Secondly, the variance in experience makes informed decision making difficult. If people don’t experience the concept in the same way, it is not possible to get valid feedback and exploit all the expertise that contributors possess. The consequent suboptimal decisions endanger the product by directing its development onto a wrong path. This leads to prolonged decision making, wasted resources, decreased job satisfaction and lost revenue.

Misinterpretation leads to suboptimal decisions and waste.

Removing the variance entirely is impossible, because we will experience even the finished product differently. However, we can greatly reduce the negative variance that creates miscommunication early in the process by simulating the intended experience. Usually, this simulation involves exploiting relevant dimensions and channels of perception regarding software product concepts, especially time and visual channels.

Creating a Reference Point

To get everybody on the same page, we need a reference point. It can be an analogy, a drawing, a paper prototype, a visualization, a functional prototype – anything that communicates the concept effectively in relation to the context. For example, I can tell you that I had a fantastic experience when rising to a stage to give a speech to a cheering audience. However, “a fantastic experience” as a concept is very vague. I could draw an analogy and further offer a reference point by saying, “It was just like riding a roller coaster: you feel that crunch in your stomach and the thrilling combination of fear and pleasure as adrenaline rushes through your veins.”

A reference point enables everybody to get on the same page.

Reference points are things we use all the time. Unfortunately, most of the time, we use them badly.

Software projects are all about abstractions. Usually there are, and should be, people with different backgrounds involved in the development process. Developers create something that has never existed before, usually based on their interpretations of someone else’s ideas. In order to communicate critical abstractions, it’s useful to create fast prototypes to bring the idea to life. Prototypes help to establish, crystallize and maintain a clear vision.

A good reference point gets all the relevant stakeholders on the same page. It operates as a mental anchor that effectively directs efforts. It enables fast iterative development, as people understand the concept and are able to give direct feedback. In many cases, a good reference point requires that the user experience of a given concept be concretized.

In our prototyping process, we use a Goal-Directed Design based approach to evaluate which elements of user experience are the most valuable. In order to prioritize these elements, we need to understand the requirements of the context, because the goals of the communication might vary from one context to another. In many cases, we might communicate the concept to multiple stakeholder groups by demonstrating the prototype, but there is usually one group that is more important than the others. Therefore, you should focus your effort by asking yourself, “Does this feature communicate the right things to the right stakeholder?” Also, bear in mind that this prioritization management is the most important (and probably the hardest) task when managing the effort you put in to creating the prototype.

Now, let’s look at a concrete example that will help you to get on the same page as me. The challenge is as follows:

The customer travels to numerous conferences, meetings and other happenings where he meets many new people. Oftentimes, he will sit at the meeting table with the people and know nothing more than their names after introductions. If he knew more about them, such as their interests, credentials, common contacts, publications and research, he would create more value by networking and influencing them more effectively. That’s why he would love to have a “Meeting Genius”, a system into which he could simply type the names of the participants at a meeting and view the participants’ relevant information in one glance.

We created a prototype of a web service to answer this challenge. In this service, one can type the subject of the meeting and the names of the participants, and with one “scuup,” get all the relevant information at one’s disposal.

Ok, now you have formed preliminary mental image of the concept, probably accompanied with some notion of whether you would use such a service and what features it should have. Let’s take a look at the reference point we created: scuup.leonidasoy.fi

After trying out this reference point, do you have more opinions about the concept? Would you use such a service? Does it lack features you would want? Is some feature especially neat? This is what a reference point does: it communicates in higher detail and therefore enables informed decisions, aligns product development resources and reduces waste.

Bryan O’Sullivan of RWH fame shared his experiences on starting your own company with other smart enough people, where Haskell plays an important role. BTW, while I did like the style and more idiomatic approach of Learn You A Haskell For Great Good, does have some very nice examples and pragmatic tips; read LYAH first and go to RWH for more details and examples. Bryan is a pretty prolific Haskellist and has published many core components built by his company on Github, not to forget his contribution to GHC to make network I/O faster. I left that session happy and convinced that Haskell is more than mature for serious work.

After the unorthodox detour of creating the Maybe monad for Ruby, I went to check out the language panel, where the audience asked various questions regarding programming languages from the panel consisting of six professionals, including Rich Hickey of Clojure fame and Gerald Sussman of Seriously You Can’t Be Asking Of What fame. Long story cut short, when asked what language one would have wanted to have invented if not his own, Lisp was chosen unanimously. And I’ve heard the same going on for over 10 years or so, and I suppose for a reason.

Next session was pretty deep stuff. I’m still collecting the various bits and bytes trying to combine all of that together; I can’t yet connect all the parts, but it was just PURE AWESOME at the risk of overusing the aforementioned adjective. Want to get your neurons firing fast? Talk to David Nolen and ask about the mapping problem. That stuff got me thinking in the same sense as Erik Meijer’s talk did with all that duality-and-flirting-with-category-theory stuff. I wish to hear more from that guy (going to browser to follow him on Twitter). Now, that’s better. For what I gathered, the main point was that there exists this problem of taking the problem from the problem domain and going to the tool (programming language) abstraction level. Certain languages give much better means/tools of building up the required syntax/mechanisms for more natural mapping, and Nolen used his implementation of pattern matching support for the Clojure language as an example. Cool thing was that it was effectively the same as pattern matching in Haskell, even though the latter has lazy evaluation whereas Clojure does not. Also, I added the book The Art of the Metaobject Protocol to my list of books to acquire.

Penultimate session was by Allen Wirfs-Brock on “Post-PC computing” is not a vision. I actually had drawn the same conclusions like probably hundreds of thousands of others had, so there wasn’t much new there. Maybe the best part was saying out aloud the phenomenon we already see happening: web browser is fading away, kind of; it’s becoming ubiqutous as the computing technology itself. Most modern (all?) OSs already have a set of extracted libraries which together provide the functionality needed to browse the web, so that when opening the application you don’t need to necessarily click the link to see some related web page show in a separate browser, instead, the application is able to render the page in itself due to built-in libraries for retrieving, parsing and rendering web content. Think of your toaster querying the price for sliced bread via REST api and showing it on the panel. That’s future, baby.

Last session was a really, really good one, even though I didn’t agree with everything Rich Hickey said (of course, I am right whenever my opinions differed from his). Rich talked about simple software design, carefully overloading words “Simple” and “Easy” with semantics most (maybe all?) people could agree with. Going deep from etymologies of both words into characteristics of software that is simple, he showed several ways by which we, software developers, creep complexity (complectify?) into code. One of the best lessons I learned there was that regarding simplicity in rather general and abstract level, it is not a question of cardinality; having many instances of something, while internally consistent, does not make something complex. That gives me more rigid basis on arguments regarding if it is actually a good thing to split a complex method into many very simple ones — I always love it when some much smarter-than-me guy me at least semi-formal ways of proving I have been right all the time, if only by intuition >:-)

All in all, I feel kind of ambivalent on getting back to home. I do miss my kids, friends and co-workers, but I also feel sad to leave. St. Louis was a city one could easily learn to love, not least due to genuinely friendly people, good food and plain awesome (sorry! that word again) Jazz. I was also lucky to meet a sweet, charming lady doing pretty involved statistical analysis with Fortran language, both of which I would have wanted to talk about way much longer if it had been possible. I also miss the guys we talked with during breaks on some of the sessions, especially the folks on the “Those Guys” team. Sniff.

Day 1: Monday

Erik Meijer started a keynote talking about Category Theory, Big Data and Monads. It seemed like there was not sufficient time to talk about monads, but his view on three orthogonal dimensions of Big Data and especially dual nature on SQL and NoSQL blew my mind. The main thing was, SQL and NoSQL are not opposite but dual in nature (dual as in dual in category theory); just reverse the direction of arrows in SQL relations and key-value stores, and you see the point. As always, you just have to love Erik’s style on giving presentations.

Then Neil Ford gave presentation on Functional Thinking. I have to say the presentation was a lackluster. The presentation in itself was good and the guy obviously could have shared lots of wisdom and knowledge, but it was really like FP 101. I guess that if some Java coder who has always refused to learn anything about FP and by some random coincidence entered the wrong room and listened to the session, he would’ve probably learned some new stuff.

About next session – I’m so annoyed I chose another session first! I really didn’t get anything out of it, as the pace was just too high and it was so specific to JVM that it just wasn’t for me. In the end I went to listen the end of Daniel Spiewak’s extreme cleverness which just made my day. This guy just rocks! Combine deep knowledge, wits, intelligence and extremely energetic (which you’ll just love) style of presentation and that’s Daniel Spiewak standing right there. Not only fascinated by the session, I learned a few new functional programming data structures on the way, but most of all, I got elated for the rest of the day — Spiewak did that just that. Seriously.

Another part in the Mindboggling Lectures series, next up was Scalaz: Purely Functional Programming in Scala by Runar Bjarnason. That certainly should have enlightened many people trying to get their heads around monads, as Bjarnason presented how some type classes were implemented in Scalaz, starting from semigroups, going to monoids, applicative functors and sneaking in monads without actually mentioning it until later in a sidenote. That stuff was pure.. um, adamantium or something — one of the best presentations. At last that made me pretty interested in Scala itself as well.

Parser Combinators: How to Parse (nearly) Anything by Nate Young was pretty good as well. Nate seemed to be pretty relaxed, informal but knew his stuff and at least I got a good intuition of how to make different parsers by combining very simple parsers using just four constant outcomes along with the unparsed part. I had read some parsec stuff before but never soiled my feet in it, and Nate’s Clojure examples were well done. Added simple regexp parser using parser combinators to my personal todo list :)

Final session I chose before ending keynote for Monday was about Making Monads Easy by Jim Duey, this time implemented in Clojure. There wasn’t anything new to me — with the exception of some Clojure syntax as I’m not that familiar with the language — but it was kinda fun to see how people learning about monads on the second or third round just don’t get it yet, because it often takes about 5 attempts or so and then you go like “come on, it was this easy?”, create a blog post about it ending up confusing the beginners with exactly the same oversimplified (or unnecessarily complex) example. Not that Jim didn’t do a good job (he did), but it just takes a few rounds to get the hang of it.

Day ended with a keynote by Gerald Jay Sussman. I do believe I got the idea, but the idea was a bit too distant for me. Basically, it was about totally different computing model, but in the end, the proporal wasn’t /that/ radical and there are already comparable systems with similar functionality. There were some very good points, naturally, and the problem described is really an interesting one. Check https://thestrangeloop.com/sessions/we-really-dont-know-how-to-compute for more.

Day 2: Tuesday

Perks of software development

The past year has been quite different for me. It has had little to do with engineering sciences or public services, but everything to do with things enterprisey; thus, I may have a particular bias that I would not have otherwise. To get us going, let me first list some of the issues we encounter in software development, in decreasing order of importance:

Incorrect programs.

A Superb Programmer Ninja writes bug-free C code with cat, but the rest of us will gladly accept all of the help that the tools and the language can offer us.

Complexity.

Software systems are becoming increasingly large, which emphasizes the importance of proper abstraction levels in programming languages — you would not write Civilization V in an assembly language.

Lack of proper infrastructure.

A perfect language with equal implementation is not enough if you lack the tools with which to write the code, analyze the code, write unit tests, and most importantly, develop new software quickly. The latter requires comprehensive language libraries, so that you don’t need to reinvent the wheel each time.

Performance.

CPU speed has increased very little over the last 5 years. In the near future, a commodity PC will have at least 16 cores; at the same time, software development will become an order of magnitude harder with parallel processing and shared state.

Deployment hassles.

With self-hosted services, this is not too much of a problem, but for standalone products, having to install tens of language libraries, several system libraries and/or runtimes, which the former depend on, and manage all of the versions with different installations quickly becomes a velocity drag you wish you didn’t have.

Pulling the curtain a bit

Any language likely to become a hit tomorrow must have been developed quite a long time ago in order to reach sufficient maturity, with accompanying libraries and tools. That leaves out many of the good candidates (sorry, Falcon fans). And with respect to correctness and complexity (which are given 1st and 2nd priority on my list) a paradigm already exists that offers the following benefits:

• Given a variable (symbol) in some scope, the attached value never differs. Remember how in math class x = y+2 always meant precisely that, meaning that such ill tricks as x = "bar" ; x = 7*86400 are never legal. Every “variable” is actually a constant!
• All function calls produce the same output when the input is the same. This is an immense help when it comes to debugging.
• Given two function calls with no common dependency, the computation can automatically be performed in parallel . This is possible because the function outcome is only affected by the function body itself and its inputs.
  High-level abstractions avoid the need to manually code such meager things as iterating a loop, selectively mapping a set of values to something else, reducing a list of things to a single item, and so forth.

Now, I would have lied in the first three sections unless we define a function to be a pure function. And the paradigm is of course functional programming, and unless you have lived in the closet for the last 50 years, it is nothing new. Actually the first such language, Lisp, was created about 50 years(!) ago, and it remains as modern/timeless as any other language. The reason why FP is once again starting to gain momentum is probably due to several factors: first, there are concurrency issues using an imperative model due to shared state. Second, many popular languages include at least partial support for the FP style development, such as list comprehensions, map/reduce, and functions/methods as first class objects, thus making the FP model more reachable for the masses. But mostly, I believe the main reason for the increased popularity is that while reliable parallel, distributed programs are certainly possible with imperative languages, building such systems with reasonable quality requirements in time and on budget is not something that the majority of software developers are cap^h^h^hwilling to do.

I kind of really wanted Scala to be the Next Big Thing. It supports FP quite well. It offers immutable variables, pattern matching, higher order functions, enough infrastructure, and already even the potential Killer App (Lift). Heck, even Twitter chose it after realizing that Ruby on Rails was not going to cut it.

But Scala does not have pure functions. It does not enforce or encourage the user to avoid state manipulation or doing many things at once at the syntax level. And the syntax is far from simple. Scala makes it easier to switch to FP, as you can always resort back to the familiar imperative style, but the downside is that as a hybrid language, it has syntax and structures for both OOP and FP, and many of the benefits of FP are lost as a result of that freedom.
And one thing that I have recently learned is that voluntary, carefully designed, self-posed constraints are often a good thing and with FP, very much so.

Then there’s a language called Haskell that has pure functions. You cannot mutate state in a function, even if you wanted to. To do so, you must wrap your values in monads, which differ in syntax and are identified as non-functions by the compiler, statically in compile time. It strongly encourages programmers to encapsulate all business logic in pure functions and to make only necessary state changes in the monadic parts. That’s Separation of Concerns baked right into the language itself. It has static type inference, meaning that the compiler can see if the functions and their arguments are valid during compilation (ie. any editor that is able to interprete Haskell code can identify whether a function call has valid signature). It has software transactional memory, lazy evaluation, and pattern matching. Haskell can be run both interactively and compiled to binary, the latter being a nice benefit when distributing the software, not to mention the performance gain compared with interpreted languages. It is easy to debug: if a function produces wrong results with some input, you know that the problem cannot be in the state of the program but it must be in the function itself. There are no classes (as with objects), but there are type classes, which practically provide something analogous to generic interfaces in OOP parlance. Testing and code coverage tools are included in the standard distribution package. It is very concise without being obscure. It really comes with batteries included.

And there’s a lot of Magical Pixie Dust.

Whetting the appetite

Functional languages are excellent tools with which to create really usable modules: with a functional paradigm, you get a uniform programming model. Because everything is either a thing or a list of things, currying (partial function application) and function composition offer an extremely versatile toolset with which to create complex software from simpler components, which are composed of even simpler components — all without being tied to the details of the data. A good example from Real World Haskell:

We have a method words, which returns a list of words in a string:
words :: String -> [String]

From Data.Char, we get the method isUpper :: Char -> Bool in order to determine whether a char is an uppercase letter. How to count the number of uppercase words in a string? The expression

capCount = length . filter (isUpper . head) . words

does the job. But what if you wish to use the ability to detect if a word starts with a capital letter elsewhere? Well, thanks to currying, you can just bind a symbol to the new function (dot means function composition — in Haskell, f . g is practically the same as f(g(x)) in mathematics):

let capWord = isUpper . head

It works because strings are actually just character lists, and the head returns the first character in a string. Due to currying, the composed function still requires one argument (string) before it can be referred to as a list of characters. This can be seen by inspecting the type:

capWord :: [Char] -> Bool

After that definition, we can use the function above, with the original code simplified to

let capCount = length . filter capWord . words

Did you notice that there are no arguments to function definition? We could have written

let capCount string = length . filter capWord . Words $ string

but that is not common practice among Haskell programmers. The string does not add information to the function definition, just noise. We want to express what kind of function we are defining, and Haskell afficionados prefer to express only the absolutely essential. Thus we have bound the function capCount to equal the right hand-side of the definition, meaning that the symbol can be replaced with (length . filter capWord . Words $ string) anywhere, always. And vice versa.

Partial application is very common in Haskell. All Haskell functions are unary, accepting only a single argument. The function add

let add x y = x + y

actually accepts only one numeric argument, then it returns a function that takes one numeric argument and returns a number. You can then create a one-incrementor with

let incr = add 1
incr 41 -- returns The Answer (42)


Reusability is also easier to achieve, as it is often the algorithms, rather than the data types that repeat in different projects and thus should be easily reused. The problem with OOP is that the methods are tied to the data, and without careful design, the data often ends up strongly coupled to the algorithms using it. Designing programs is not about the data per se, but rather about the flow of data and the operations performed on the data. It’s all about functions; how to transform input and/or current state into output (or another state).

The claim

So, I believe that Haskell is the Next Big Thing for several reasons:

• FP is the future. Programming mission-critical, complex systems in a 64-core system with imperative languages just doesn’t cut it.
• It is simple enough. Ok, the Haskell learning curve can be steep, but mainly for the FP paradigm itself. Monads are much simpler to use and understand than they are to explain — though it may require reading an article or two in order to grasp them. But Haskell does not have anything like the syntactic jungle of C++ or Scala that must be learned.
• Library and editor support is available and has been for over 15 years. It’s far from immature.
  Haskell has received a great deal of positive press lately among common programming blogs, and most importantly…
• …it is favored by many Alpha Geek Programmers. Blame me if Haskell isn’t at least where Ruby was in 2007 by the year 2016.

Naturally, there are other languages that fit rather well here, one of which is Clojure, a JVM-based, Lisp-like language, also largely influenced by ML and Haskell. Released to the public in 2007, it is not yet all that mature at this stage, but still, it has received a lot buzz recently and for a reason.

I’m still a Haskell novice. In spite of the fact that I have just started to really learn FP and Haskell, I often run into a situation in which I am coding some function and I think that I am about halfway through figuring out a solution or that perhaps another third is missing from the working solution. Suddenly, I realize that I have the complete solution right before me, after, for example, adding a method call or two to some handy chain of composed function calls. Most of the time, I end up wondering how my mediocre creations can accomplish so much in so little, while lacking the finesse and elegance common among more seasoned Haskell veterans.

Luckily here at Leonidas, I’m surrounded by much smarter people, and I know that I will learn a great deal in the near future. There’s a nice surprise around the corner.. . Stay tuned!

Credits to Alexandre Duret-Lutz for the Goedel, Escher, Bach photograph.

To receive an invitation, please send an application to Spartiates@LeonidasOy.fi. Describe how you will raise us to the next level. Attach your CV, and we will get back to you as soon as possible.

See you in SoturiSauna!

-Aleksi