Swift Blurs the Lines of Programming Paradigms

Swift Paradigm

When Apple created the App Store, it became instantly clear that empowering developers across the globe to build software for its platforms was a winning strategy. However, Objective-C, Apple’s age-old programming language, became something of a barrier to iOS and OSX development. Due to its unique syntax and language limitations, both people wanting to learn computer science fundamentals and seasoned veterans looking to implement elegant language paradigms were required to jump hurdles to do so.

Today, Swift has emerged to fill that void for both groups. When Apple’s newest programming language was introduced to the tech community at WWDC 2014, it was received with the general fanfare we’ve grown accustomed to seeing from any announcement the lauded tech company makes.

Here’s a language that essentially marries the readability of Python with the speed of C++. It’s concise, type-safe, and highly versatile.

Swift’s Versatility

Though Swift doesn’t attempt to conform to one bucket of categorization, it does lend itself to some paradigms better than others.

Let’s explore three in particular:

1. Object-Oriented Programming

With predecessors of Objective-C and C/C++, Swift inherits (pun intended) a lot of OOP patterns. One could essentially rewrite his or her Objective-C program in Swift and change little more than syntax. As OOP is typically the first architecture paradigm developers learn and the one they use most often in industry, staying true to its roots isn’t a bad thing.

However, Swift is entering its awkward adolescence. It’s seeking to break from its parents and forge its own trail. There’s no denying that OOP has its limitations; it doesn’t always scale well, and it favors inheritance over composition. Virtually everything in OOP is an object, and you sometimes need a verb.

Still, despite becoming the 15th most popular programming language in less than a year and a half, Swift still holds to these OOP paradigms that aren’t in vogue. Swift programs typically aren’t reactive, and its omnipresent UIViewController classes perpetuate OOP’s rigid reputation. Promises and Futures are nowhere to be found.

What gives? Isn’t Swift supposed to be the language of tomorrow? In many ways, it is. But it’s also the language of today. OOP isn’t dying any time soon. Sometimes, it’s the right tool for the job — and Swift does it well.

2. Functional Programming

Functional might not be a part of Swift’s DNA, but the open-source community is finding ways to make it a more functional language. Swift’s closure syntax is greatly improved from Objective-C’s block syntax; it also has reduce and map functions, staples of a functional language. It favors constants over variables.

Generics in Swift really separate it from Objective-C as a language that can use algorithms and expressions without being attached to a specific type. However, to call Swift a “functional” programming language is a stretch.

Functional programming is a paradigm designed with lambda calculus in mind — a model for creating solutions by sending inputs to functions that produce outputs. That said, you might be thinking that pretty much every programming language is functional. Well, the kicker is that in pure lambda calculus, everything is a function. Though that doesn’t translate well to most programming languages, it means functions are first-class types in functional languages. Passing functions into functions into functions to produce an output is commonplace.

Swift is functional when it needs to be, much in the way that Scala is object-oriented when it needs to be. It can operate as a functional language, but its programs typically aren’t structured in such a fashion. They’re usually littered with variables, and collections are often mutable. Such characteristics are not commonplace for functional programs.

3. Generic Programming

Swift is clearly a great step forward in battling the shortcomings of OOP — it’s multiparadigm OOP and functional. But where it’s really setting trends is as a generic language.

Generic programming is a style in which types are not explicitly specified. Generics, as the name implies, are the most obvious example of generic programming in Swift. The types in a generic function are known at compile time, but they aren’t dictated by the function definition. Many different generic types can reuse the same code — and, as we all know, less code means fewer bugs. This was a sorely missed feature in Objective-C.

So why is Swift so popular? Sure, the syntax is great, it’s an open-source language, and it’s type-safe. But where it really shines as a generic programming language is with protocols. Apple engineers hail Swift as “the first protocol-oriented programming language.” To be fair, interface-based architecture might not be a new idea, but Swift definitely improves upon it.

In protocol-oriented design, the rigid inheritance hierarchies of OOP are replaced by protocol implementations. This design promotes loose coupling between types. With no derived classes or abstract base classes, types aren’t littered with base class data that shouldn’t be shared. Best of all, the pitfalls of multiple inheritance (or, in Objective C’s case, the lack thereof) are avoided.

Protocol-Oriented Example

Let’s say all view controllers in your app need to implement the same method. In OOP, a couple of problems arise:

1. Many Base Classes

A traditional implementation might be to make BaseViewController, BaseTableViewController, and BaseCollectionViewController. You’d then cross your fingers that no one would come along and create a view controller that doesn’t inherit from one of your beautiful new base classes.

2. Code Duplication

The same logic would be duplicated in all three classes! More code means more bugs.

In a protocol-oriented approach, you could make a protocol and then make your view controllers conform to it. At this point, we’re still in the same pickle. With Objective-C, we’d have to make each subclass of UIViewController conform to the protocol, so we’d make base classes and not be much better off than before. Not so in Swift — the pre-existing classes can be made to conform to our protocol via extensions.

extension UIViewController : MyProtocol {

  var myName:String {
    get {
      return title
    }
  }

  func printName() {
    print(myName)
  }
}

Success! But Swift doesn’t stop there. Let’s say you have another type that implements the same protocol. printName doesn’t do much. The OOP impulse is to put that method in a base class. With Swift 2.0, protocol extensions allow the protocol to implement that method.

 extension MyProtocol {

  func printName() {
    print(myName)
  }
}

Code duplication is now eliminated without the sharing problems inherent to OOP.
So what type of language is Swift? It’s whatever it needs to be to get the job done. Sometimes, it’s object-oriented; occasionally, it is functional. And it really shines when it’s generic.

Swift can be what you want it to be. Its familiar syntax, rich feature set, and amazing community make it a great place for programmers of all levels to broaden their horizons.