Programming is hard – Part 2

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

October 12, 2011

NOTE: You can also read Part 3 of this blog series.

The debate about the complexity of scala ensues. As I previously wrote, programming is hard! Trying to conclude how easy or hard scala is based on language constructs isn’t feasible.

In a really active thread on the LinkedIn Scala Enthusiasts group, someone posted:

…encapsulation is the most important concept in OO and plays no role in Functnal Programming. So these 2 paradigms are not naturally combinable. I think designing fully and only Functional language compilable to JVM bytecode with ability to call methods of Java classes/instances would be much more natural combination.

I’m sorry but this point is totally wrong. The first part where the author suggests that object oriented and functional programming concepts are not combinable is based on a totally false premise.

This can be demonstrated by the fact that languages like Python allow you to use classes and functions all in the same module. You can model things with classes, but capture important operations used by your objects in functions that aren’t part of your class structure. The class methods can invoke functions and the functions can use the class structures in a symbiotic way. This is because not every problem requires the ceremony of classes. In simple, contrived examples, I usually don’t need to chop things up like this, but when I’m working on complex, real systems I like having options available, and sometimes mixing functions and classes together is alright. Think of it like nouns and verbs (read this side article, it’s awesome).

Scala supports this too by letting you put functions inside objects, essentially namespacing them. You can build an entire module as a collection of functions with no classes at all. Define some classes, and you can them using each other just like Python. This is where the functional aspects can be outside the object oriented nature and hence defies the authors assumption that OO and functional programming don’t mix.

The author is also assuming functions and objects are on the same level. This isn’t necessarily the case either. I’m sure we have all seen one article or another that talks about objects using examples like circles/squares/shapes or cars/boats/James Bond boat-cars and dealing with things like multiple inheritance and the diamond problem. In these situations, we seem to have the solution in place when we reach the right structural hierarchy of classes. In contrived examples, this is often the case, but in the real world, we rarely are done when the class structure is defined.

The classes have to accomplish something, like sort some data, digest an electronic invoice, generate a PDF report, or some other operation. We have the ability to use functional programming for some of these tasks. For example, if we are consuming an electronic spreadsheet of data, it may perfectly fit into a foldLeft operation. Various fold calls can be imbedded in the different concrete subclasses of our hierarchy. We instantiate the object based on the invoice type and then we functionally digest the file. If there is commonly used functionality between each subclass, we can abstract it up the hierarchy. Our fold operation may tap some abstract functionality, like readingTheNextLine. This type of abstraction is what we do when we need to handle physical files as well as virtual ones. So we have crafted a functional construct connected to an object oriented one.

This example demonstrates that functional and object oriented structures can easily be mixed together, QED, defying the author’s assumptions. Because scala makes it easy to mix-and-match code together, it is strongly empowering the user. My favorite synopsis of scala is in the video interview of David Pollack on the FLOSS vidcast.


Fast forward to 04:00-04:45 to hear David Pollack give a 10,000-foot summary of the Lift web framework. But more importantly jump to 05:54, where he taps his head saying something like “scala makes it easy to capture what was in my mind’s eye.”

As Ted Neward described in a column, working on software is one of the hardest professions, because everything we deal with is purely abstract. Programming is hard! You can’t crack open a computer and point out the threads, the objects, the functions, or the actors. A computer is a series of electronic pulses that we are trying to manipulate through abstractions. Even theoretical physics must eventually bow to actual observations. Einstein’s theory of gravity and it’s implications for bending light wasn’t accepted by the academic community until a scientific team traveled to a far away location to measure stars during an eclipse.

The complexity of scala is governed by the problems we are solving, how well we can simplify the parameters into constructs that allow us to write a solution, and how well we can communicate with our team. I have never worked on a team where were all perfectly in sync on the same page. Someone was usually more seasoned, and one if not more of the people were green newbies. Saying that scala is too hard because everyone is on different levels is a red herring.

All programming languages suffer this problem. The worse thing you can do is isolate yourself and not have regular team meetings and communicate. The team needs to get together regularly and get on the same page. This takes active work, code reviews, team discussions, brown bag lunch seminars, and more. I hate to break it to you, but that is what teams do. Programming is hard, and we must help each other out, not abandon solutions.


Submit a Comment

Your email address will not be published. Required fields are marked *