What's the Future for OO Programming Languages?
What's the Future for OO Programming Languages?
Object-oriented languages have been with us for a long time now, but what does their future hold? Is there one? Or were the functional cowboys just getting a leg up?
Join the DZone community and get the full member experience.Join For Free
Classify programming languages: Build a model that predicts a code's programming language based on its text. Content provided by IBM Developer.
I spent most of my software career either writing, designing, or architecting solutions built with a heavy object-oriented (OO) bias. I simply cannot even estimate the number of lines of C# that I’ve written or read. Even now, I love the abstract elegance of good OO code.
However, I’m left wondering how much of a future it has left.
Here are a few thoughts about where mainstream programming is going, and what choices programmers will favor.
Microservices, the second and more complete incarnation of Service-Oriented Architecture (SOA), allow us to decompose our logic into reusable services that are accessed via open network protocols. This is crystallizing into an accepted convention of REST/HTTP. The code for our microservice, i.e. what’s behind the API, doesn’t matter to the outside world. Is it OO? Is it even compiled? Who cares?
Indeed, programming web APIs is functional programming in its very nature.
By contrast, take a look at some of the implementations of service interfaces in OO languages (e.g. .svc and .asmx in C#) and you’ll notice that they have shoehorned in an OO interface/class structure when in fact an API call invokes a function. You find that to even create a “Hello World” you end up with a binary of an amazing size, because of all the plumbing that’s being done for you under the bonnet.
I don’t know how many of you have used AWS Lambda, or its equivalents (Google Cloud Functions, Azure Cloud Functions). This is a nascent area for programming, which is coming into being because of cloud platforms. Essentially, serverless functions are pieces of code that are invoked by an event. However, they don’t have a permanent host hence the “serverless” moniker.
When an event trigger occurs, such as a message being placed on a queue, the cloud platform spins up an instance to run the code that handles the event. When it’s finished, the instance can terminate and hence free up resources. This is an amazingly powerful concept because it really is getting as close as possible to a pay-as-you-use model.
And the programming paradigm? Functional. Dynamic. You invoke a function to handle the event and the data that comes with it. Ideal language for this type of scenario? Python.
What you can achieve with a few imports and a few lines of code in Python requires a mind-bending amount of references and components in many formal OO languages.
User interface (UI) is a very interesting area from a technology point of view. My old boss always used to say that the only thing a user ever knew of your software was the screen in front of him. You’d better make that good or your users will all assume everything else is rubbish as well. No matter how unfair, that’s the way it is.
As a result, UI is the area where the real pace of change is felt. You only need to go back a couple of versions in many pieces of software (or websites) and you will cringe at the clunky interface you used to take for granted. UI sells.
I see UI as one of the last great outposts of OO programming.
The open source movement, combined with open package repos and package managers (e.g. NPM, pypi, NuGet) have massively impacted on the way we use code. Software is built on software, and if a problem has been solved before, well you’d be insane not to reuse the solution.
This is an interesting one to watch. Frameworks and framework extensibility were a case study for OO design patterns. Now, the functional world has found its own patterns for extensibility and reuse. I’m interested to see what wins out in this area.
The trend away from installed on-premise software to Software-as-a-Service (SaaS) is only going to accelerate. This will build on the points above, but the real demise will be felt when companies are decommissioning system after system from their own datacenters to avoid having to maintain and support them.
Add to this the shift to cloud. Do the math – the cloud represents huge savings and huge opportunities if embraced correctly. Less so for pure lift and shift of on-premise systems, but organizations that are architected from the ground-up to take advantage of cloud and SaaS will have huge competitive advantage. Again, this is more of the same: APIs, Serverless Functions, UI.
DevOps is a hot topic, and one close to 345’s hearts. If you look at what’s going on there you find a lot of scripting going on. Python’s very strong, but so is Ruby. Bash is very procedural, PowerShell mostly procedural but also made to support .Net. I think Python is going to win big in this area over the next few years. Just look at the AWS CLI. Python is also widely adopted within Google.
This has been a whirlwind tour of a big subject area, sprinkled with a thin layer of thoughts. By all means, add your own input to the comments.
I think the big growth areas in programming are going to be:
- Further decomposition into microservices and APIs.
- Serverless functions to handle asynchronous processing.
- SaaS applications replacing installed applications.
Of these, I think the first two will be dominated by functional programming and dynamic languages.
If you’ve been used to OO, you’ve probably told yourself time and again that you’re doing it the “proper” way and those functional programmers/scripters are cowboys. Free your mind to accept the fluidity of a functional language: The possibilities are huge. And realize that the scripters aren’t cowboys after all, they just have a different way of thinking. They don’t rely on compilers, they rely on tests. Which is a good thing.
Published at DZone with permission of Andrew Rivers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.