Application Design – Code Creek

Functional Programming Vs. Object Oriented Programming

Object oriented programming has been the de-facto programming methodology since they day I learnt that there is something called computer programming. Several of the most popular programming languages are primarily object oriented programming languages. The most commonly asked interview questions for programmers are about object oriented programming.

Until, functional programming just blew up a few years ago. Functional programming languages have been there since the 1960s mind you, but only a few years ago they gained traction among ‘commercial’ developers. I found a ton of people learning Scala and lambdas and observables and all the associated jargon. A group of us jumping ships and embracing functional programming as the way to go for all our new projects. And another group of us sticking to the familiar grounds that is object oriented programming.

So far I’ve done two projects in the functional programming style, both web applications. One in Scala and one in Java (Spring Reactor). Here’s what I’ve learnt so far as contrasts between Object Oriented Programming and Functional Programming.

Core Principle

The first difference that we need to appreciate is the core principle guiding these methodologies. Whenever I see coders struggling to adopt functional programming, it is because they don’t have a grasp of this.

Object Oriented

In object oriented programming, we think of everything as objects with state. The flow of the application is dictated by change in state of the objects involved.

Functional

In functional programming, we think of everything as operations. The flow of the application is dictated by the chain of operations.

Design Patterns

If you are like most other programmers, you would have learnt a bunch of design patterns to apply in your projects. And I bet many of them are not just ‘design patterns’, they are ‘object oriented programming design patterns’. You need to even unlearn many of these. If you try to apply these common design patterns when you do functional programming, it will be like hammering a square peg in a round hole.

For the last couple decades or so, object oriented programming has overshadowed all the other ways of programming and this has one bad side effect – so much of the learning material depends on real world analogies. We’ve all come across things like the Animal --> Dog --> Dalmatian kind of analogies right? Well you need to forget all that and realise that abstractions are only there to lighten the cognitive load.

Computer doesn’t do dogs and cats. Computers do sets of operations on very basic units of data. Data like bits and bytes. Functional programming relates more to this attitude in a programmer. You are not working with simulated models of objects. You are taking an input, doing some processing and giving an output. Try to apply that to any programming task that you do. For example, a web service, takes a request as an input, does its processing stuff, and then sends a response as an output. This can be broken down into several levels to achieve cognitive ease, by breaking down the processing into multiple functions, and then chaining them by giving the output of one function as the input to the next function.

Choosing between the Two

It is not simple to classify an application, because most applications fall into multiple categories for purposes like these. Think about the core purpose of your application and make your decision based on that.

Object Oriented

Object oriented programming is preferable when you are representing a world of objects. For example a simulator, or a video game.

Functional

Functional programming works well in scenarios where your application is a processing pipeline. For example a event stream processor or a data processing API.

When you are trying to choose between the two, do not think of peripheral activities like logging, IO (even database updates). Rather, think of the main purpose your application is solving for its user. Is it giving your user an object-state model that they can manipulate? Or is it providing an engine that transforms their input and gives them an output?

Combining the Two

In real world, you probably are going to combine the two programming paradigms, rather than use strictly only one. Functional programming seems like a good fit for a web service, but some of the components are still better represented by an object oriented model. We can think of the web service as a series of functions that, in the beginning take in a request, and in the end emit a response. But entities like service and repository can still stay as objects. In fact, a pure function will not have side effects, but this is hardly useful in the real world right? We need to almost always have side effects – update a database, write to a log file, send out an email and so on.

The Code

The most visible differences between the two programming methods is when you look at the code. Some important differences are –

Object Oriented

Objects are the core entities. The program flow is usually instantiating objects and modifying their states. Any processing that is done, is as a means to change some state.

Control flow in object oriented programs is done through simple and traditional constructs like loops and if-else blocks.

There is a global scope, then there is a session scope, then there is a thread scope. Or simply put, there is always some global state from where you can get your environment variables from. The ‘context’ (that holds things like current user, configuration parameters etc) are available from their respective scopes.

Concepts like threads and concurrency are handled by the application code. Even if you use a multi-threading friendly framework, you still might have to declare what is thread-safe and so on.

Functional

Functions are things. You create functions and assemble them in chains. You can assign functions to variables and pass them as arguments to other functions.

Control flow in functional programming is done by chaining, filtering and recursion. Streams are preferred to collections.

There is only a local scope. In functional programming, the best practice is to provide everything your function needs as arguments. The ‘context’ (that holds things like current user, configuration parameters etc) gets passed in as an argument to all functions that need it.

Since a ‘global state’ is not even assumed, programs are by default thread safe. And most functional programming platforms manage concurrency by themselves, upon this same assumption.

Conclusion

To put in a simple way, when you are doing functional programming, don’t think of objects and types – rather, think that you are making a lot of small black boxes. Each one takes an input and gives an output. And then you’re arranging all those black boxes to make a useful application. If you can grasp this, you’re probably going to have a very easy time settling into functional programming.

Please Stop Infinite Scrolling

I think this post is more like a follow up to my previous post on whether to use SPAs or not. Confession: I started writing that article, and this one, because of a website that completely irritated me. It was a matrimony website. If you didn’t know, matrimony websites are like dating websites, but you skip the dating and go straight to the wedding. The interfaces are made very similar to shopping sites – in fact it actually feels like a shopping site for brides and grooms.

Of course I have a problem with the ideology of those sites, but I’m here to talk about this particular one – and what irked me about it the most. The fact that it was an SPA was obviously off-putting because the concept of SPA was deliberately and unnecessarily thrust upon the poor unsuspecting wife-shopper. But

Where am I?

I have no idea how much I have already seen. A page with 16 or 20 items which I can checkout and then click on a ‘Next’ button to see the next set of items would have been so much clearer and easy to use. Without knowing how much I have seen and how many more is left, I don’t even know whether I should keep scrolling or whether I should give up. If there’s only another 10 items to checkout, I’ll continue browsing to checkout everything. But if there’s another 2000 items, I’d probably give up.

There’s no way to know that, when the page does ‘infinite-scrolling’.

How to Get Back to Where I was?

After scrolling through a countless number of items, what if I scroll back to the top for some reason? What if I refreshed the page? What if I want to look at the item that I saw a while ago? These are all not even possible when you are infinite-scrolling. You have to scroll back up all the way and find that item again. You have to scroll all the way down if you accidentally refresh that page.

Think about the User

I think the infinite scroll is a classic example of over engineering of a user experience. A classic case where a designer forgot all about user experience and just wanted to be fancy for the sake of their own vanity. Things like that are the bane of user interface design. The designer is so proud of something they did that they completely forget to get feedback from UX testers. Or even from actual unhappy users. The worse thing is, they probably actually spend more money on doing this, over the simple, easy-to-use traditional way.

Sometimes I Need to Reach the Bottom

This is the problem that I actually faced, and made me go on a rant on my blog. The menu I needed was at the bottom of the page. I had to scroll down to the bottom. Only, when I scrolled, the page just loaded more items and I had to scroll again. Then it loaded more items. After doing that a few more times, a brilliant idea struck me and I pressed the ‘End’ button – on a Mac, the end button takes you instantly to the bottom of the page. And surprise! Before I could move the mouse and click on my menu, the page loaded a bunch of items and the menu went back out of view. Not only I couldn’t click my button, the page loaded a ton of content that I wasn’t even interested in.

It’s Slow

Making one server request for a page displaying 25 items, is often faster than 25 separate requests for each item. Significantly faster. In most implementations of infinite scrolling, the page makes more and more requests as you scroll. Also, the experience of waiting for a second and seeing 25 items, is better than the items loading one by one with a fraction of a second gap in between. So infinite scrolling is not only actually slower, it also amplifies it’s own slowness, by reminding the user often that there’s something loading.

What’s Better Then?

What’s better is the plain old pagination. Don’t fix what’s not broken!

Do I know how far along I am, browsing the search results? Yes! Because a list of page numbers on the bottom always show me which page I am on, and among the list of the ‘finite’ number of things on each page, I can easily get back to where I was.

I can scroll down and see the footer, use the footer menu if there is one. My browser doesn’t have to load a ton of content that’s not useful at all to me. I get to have a calm peaceful life.

And the page doesn’t have to load a run a lot of JavaScript code if it’s avoiding fancy things like this. No matter what fancy techniques you use on your page, they will never beat speed. A snappy fast loading page, with familiar user experience is much better than fancy pages with things like infinite scrolling and animations.

Just do pagination if you’re showing me a catalog. Please. Thank you.

403 vs 404

The most recent dilemma I faced at work is to decide between returning a 403 (Unauthorised) error as against a 404 (Not Found) error in an API GET call.

The scenario is a resource does not exist on the server, and a user has made a GET call for that resource. The application as part of it’s normal execution, does an authorisation check and reports a 403 error. Now my users are getting confused – have they tried an invalid resource ID or are they having problems with authorisation?

Thinking puristically, we had initially decided to return the errors as is. That is, a 403 would be returned always, even for resources not found on the server. The reasoning was that this benefitted security. It is better to not even let an unauthorised person know whether or not a resource exists. This was an easy decision and doesn’t need much convincing the product mangers. When you say it’s for security, it almost always gets accepted.

But this time around, the decision differed. The same people who had decided 403, now suggested 404. It turns out, the alleviating the users confusion between whether they didn’t have authorisation or whether they’ve made a mistake in the resource ID or whether the dog ate the resource, and so on, was much more important that security.

We went with returning a 404. First the application checks for the resource existence, returns a 404 error if it does not exist. If the resource does exist, we check for authorisation and return 403 error if the user does not have authorisation.

The lesson learnt is that purist attitudes like “correct design” or “security first”, will almost always take a back seat to user experience. Users will not choose your application because it’s architected well or it is secure. Users will choose the application that’s easy for them to use. If you forget this, you will end up with unsatisfied users, who you will not be able to convince that you made decisions for better security or best practice or whatever else.

As a software maker, it’s your responsibility to make software that is first comfortable for your user to use, and then, still ensure that it is secure. So not just for “403 or 404?”, for any such conundrums you face while creating software, remember, customer satisfaction will always beat other factors that may contribute to your decision.

To answer the question “403 or 404?” – Do what your customer will like.