Today I want to talk about programming, particularly, programming paradigm.

A quick background

I spent a year learning and writing Scala, which is a fascinating language. But I could not get my head around why we wanted to write functional way. And Martin Odersky even said this in one of his talk:

“if you have to inject dependency to your code, something is wrong”.

Probably not exactly the same words, but close enough.

After that year, I switched back to writing C#. Then I suddenly got a hit about why writing functional is such a joy. The code can be much more concise, so easy to write test, and naturally supports concurrency without using lock because no state is shared. Everything starts making more sense.

Give a talk about it

My current director asked me to give a talk about using functional in the project I have been working on. I told him yes, but I am not sure when I will have the time to do so. I actually like giving talk to the team. It feels like sharing your thoughts and learn from each other.

I did it on a few different topic after I joined Starbucks. I gave a presentation about my research long time ago in front of couple hundred people, I enjoyed it. Unfortunately, I always find it challenging to make the commitment  to become a regular speaker in conferences. I admire those people who can.

But how do I really talk about functional programming to the people who have never done this before, when myself is not even a guru of functional programming?

The other day when I was running, a few slides came up in my head. So my idea is using them, hopefully.

My potential slides

It is just a tool

First, forget about the word “functional programming”

It is possible that some people will be offended. So I have to make the claim that this is only my personal opinion.

Second, it is important to remember, “functional programming” is just another programming paradigm. It is a style, and it is a tool to write code.

We use the right tool at the right time for the right job.

It is the same idea that I will probably not use a hammer to mow lawn, even though it might work. I will use a knife to chop vegetable or meat, not a scissor, even a scissor will definitely do the job as well.

Choose the tool wisely.

So choose functional paradigm when the situation is right.

I particularly like  Anjana Vakil’s talk about programming across paradigm, if you never watch it, I strongly recommend it:

Different perspective

The following is how I believe most people consider a good software product:

If you Google “characteristics of good software”, pretty much the same thing.

• Workable: the software is usable, in a working state, and it can realize business values;
• Scalable: the software can be scaled in terms of performance, the number of users, as well as the number of business cases.
• Testable: the software can be tested from the unit level.
• Changeable: I like to say the word “changeable”, which means the team (not just the individual who originally writes it at the first place) can comfortably make change to the code. Others may prefer “extensible”.
• Readable: The code is readable and understandable, or the software itself is well documented on the business case.

Note: extensibale and scalable are 2 different things here. If you notice, scalable is referred to the software can scale to more business cases, while extensible is referred to any developer can make change to the source code.

There is a reason a triangle being there.

The bottom is always “workable”. A software must work. If a software does not function, constantly crash, or does not deliver business values, nothing else matters.

Therefore, from a company’s perspective:

It is paying for a workable software that can deliver business values and meet business requirements. The biggest expectation from a company’s perspective is “it works”.

Next expectation from company’s perspective is, “can the software scale to meet more requirements”.

Generally, a company cares less everything else in the source code, unless that is a software company (maybe, hard to say, we all have heard how poor Oracle is written anyway). Therefore, no one will care how beautiful the code is written, or if it is using functional, procedure or imperative.

Only developer cares.

Actually, I probably should say only developers with self esteems care.

In contrast to the previous slide, the following is from software developers’ perspective:

Developers still care about the final product work. But we all know how easily a developer can be distracted in his/her own interest:

In the reversed order, developers care more about the things like how beautiful the code is written. Interestingly, the more ego the developer has, he or she is likely more focusing the things on top of the triangle.

Having developer ego is normal, in fact, it may be a good thing sometimes. It may not be sometimes though.

The funny thing about those things are important to developers, are naturally supported by functional paradigm:

• Readable: small and single purpose functions, easier to reason the code logic, thanks to deterministic fashion.
• Changeable: this may not be true for someone is new to functional programming; however, since FP advocates function composition, it is actually true that it is easy to make a change to composite existing function to make a change. Additionally, because it is designed to have no state shared and ideally each function is pure, it is less likely to impact existing business logic when making a change.
• Testable: I did not believe this before, but it is definitely true that writing unit test for functional code base is way much easier and faster than writing unit tests for imperative style. No mocking framework is needed, and property-based testing is supported.
• Scalable: One big advantage of functional paradigm is its strength in concurrency handling. Because it is so easy to make change, the source code can also be scaled to meet different business requirements.
• Workable: nah, who cares if it works, it is beautifully written.

Not: functional code is generally/arguably considered hard to understand. That is actually caused by developer ego. As I mentioned earlier, it may or may not be a good thing. If the ego is too high, abusing functional style can be intimating for others to read. But it does not have to be that way.

What does it mean?

So we see company and developer have different perspective when looking at a software and its source code, but what does it exactly mean?

Of course, writing a workable software is the most important thing, because that’s what developers are paid to do. Also, because developers have ego, and different people like to use different paradigm, how do developers work together building a workable software product?

The answer is: modularization.

Other people may see it as Microservice architecture.

What?

Yes!

No matter we are building a client application, or a backend application, we will write it into small modules. Each module represents a business feature, and then we stitch them together.

Each module is communicated through contracts, i.e. events driven. Now each module can be coded in different paradigm.

Some module may be good to use functional paradigm because it has a lot of asynchronous processing, another module might be better to use imperative. It does NOT matter. A paradigm is just a tool. Use it in the right situation. I recommend to adopt functional paradigm in pure business logic.

Conclusion

This is an angle I haven’t seen very often:

• writing modularized application so developers can avoid paradigm difference….