[swift-users] Comparing POP to OOP

Jon Hoffman hoffman.jon at gmail.com
Mon Mar 7 15:53:05 CST 2016

> On Mar 6, 2016, at 11:53 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> on Sun Mar 06 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:
>>> On Mar 6, 2016, at 1:12 AM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
>>> on Sat Mar 05 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:
>>>>> On Feb 25, 2016, at 7:35 PM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
>>>>> on Sun Feb 14 2016, zhaoxin肇鑫 <swift-users-AT-swift.org> wrote:
>>>>>> I have not read your blog. But in my opinion, what Apple called protocol
>>>>>> programming is actually so called functional programming. It is not object
>>>>>> programming at all. It uses protocols and structs to avoid object
>>>>>> programming.
>>>>> I don't think most functional programmers would recognize
>>>>> protocol-oriented programming as what they do.  It is true that one of
>>>>> the main benefits we see in protocol-oriented programming is that it
>>>>> allows one to use *mutable* value types, instead of classes, in
>>>>> polymorphic contexts.  Functional programming is largely concerned with
>>>>> immutable data, where the distinction between value and reference
>>>>> semantics disappears, and it doesn't matter if you're using classes or
>>>>> not.  But the main thing in FP is the use of higher-order functions,
>>>>> which Swift enthusiastically supports, but have nothing whatever to do
>>>>> with protocol-oriented programming.
>>>> Your e-mail touches on one of the things that excites me the most
>>>> about Swift.  As you say “But the main thing in FP is the use of
>>>> higher-order functions, which Swift enthusiastically supports, but
>>>> have nothing whatever to do with protocol-oriented programming”.
>>>> Swift isn’t just a Protocol-Oriented programming language or an
>>>> Object-Oriented language or a functional programming language it is
>>>> actually all of them and more.  While other languages attempt to
>>>> support different paradigms, in my opinion, Swift is one of the few
>>>> language that actually does a good job at supporting multiple
>>>> paradigms.
>>>> In the conclusion section of my post, I mention that while I pointed
>>>> out a lot of ways that I believe POP is superior to OOP I would not
>>>> say that POP is a clear winner over OOP.  
>>> It would be interesting to see where you think OOP has a distinct
>>> advantage due to fundamental properties of the paradigms (rather
>>> than artifacts of an immature implementation of protocol language
>>> features)
>> I would not say that OOP has a distinct advantage over POP based on
>> the fundamental properties of the paradigms.  However, if I were
>> pressed I would say that OOP does have an advantage over POP in the
>> area of data structures because of POP emphasis on value types over
>> reference types.  
> “Protocol-oriented” doesn't mean “no reference types.”  It means you're
> not forced into reference semantics just because you want polymorphism.
>> For example we cannot create a linked list with a value type.
> Not true, in fact.
>  enum List<T> {
>     case Empty
>     indirect case NonEmpty(T, List)
>  } 
>  var x: List = .NonEmpty(3, .NonEmpty(4, .Empty))
> There are other ways, but that's the simplest in Swift.

I stand corrected; I neglected to think about using the enumeration.  Yet another blog post coming from our conversation.  

>> If we tried we would get a compile time error that says: “Recursive
>> value type ‘Type’ is not allowed.
>> There are two arguments that I could make off the top of my head
>> against my last statement.  The first argument would be: Is preferring
>> value types to reference types actually part of OOP.  
> I presume you meant POP.  Being forced to use reference types is part of
> OOP.
>> I will address this in my next e-mail where you ask me what I mean by
>> my statement that POP is about so much more than the protocol.  The
>> second argument would be that we are not limited to value types with
>> POP and we are able to still use reference types.
> Exactly.
>> While it is true that we are still able to use value types 
>> with POP
> reference types?

Yes sometimes the fingers don’t always type what the brain tells them too.  :) 

>> however if we take Apple’s recommendation and use value types
>> for our custom types we really should try our best to avoid reference
>> types.  It could get confusing if some of our types are reference
>> types and some are value types especially for larger enterprise type
>> projects.  
> No, some things are fundamentally references, as I noted in the talk:
> https://github.com/ASCIIwwdc/wwdc-session-transcripts/blob/master/2015/408.vtt#L3082
>> Luckily in XCode with have the quick documentation where we can hold
>> down the option key and click on the type in question to tell us if it
>> is a value or reference type however we do not have that option
>> outside of the Apple’s ecosystem like when we are developing Linux
>> applications with Swift.  Therefore we need to be careful on how and
>> when to use reference and value types.
> You always do need to be careful about that, regardless, because they
> have different semantics.

You are correct however my point with this is with other languages like Java and C# our custom types are reference types. As developers we know this and develop our applications to take this into account.  With Swift it is not always clear what type was used to create a custom type especially when we are working outside of Xcode. 

Lets say for example that I created a framework that has several custom types and this framework can be used with Swift on the Linux platform.  If I do not document my framework well enough it could be hard for other developers to know if I implemented the types as reference or value types without looking at my code.  Therefore with Swift we need to take extra caution on how we use reference types because developers could assume they are value types when they are not.  

Now if Apple could port Xcode to the Linux platform... :).  Just one more thing to do in all of your spare time, right?  :)

>> Where I really think OOP has a very distinct advantage of POP is that
>> it has been around for so long, has been vetted in more projects then
>> either of us can count and it is very well documented.  
> Yes, that was the one argument I thought could be defensibly made for
> OOP over POP.
>> I don’t know if anyone can really say that Apple has documented what
>> POP is and isn’t very well 
> Absolutely, we have not.

This has allowed for us to experiment a little and figure out what we think it should be.  Maybe we will come up with some good ideas that you did not think of, or maybe we will go down the wrong path that you will need to correct .  Kind of like our conversation right now.  
>> which is the reason I wrote my book on POP and why I plan on writing
>> additional posts on it as well.
> I'm looking forward to seeing more of that, and I like to help you
> capture more of what we mean by POP.

I can definitely say that our conversation has helped me understand more about what Apple understands POP to be and I welcome any help/advice/feedback that you can provide.   Consistency is important to help people adopt POP.


>> If you do a search on the Internet for Protocol-Oriented programming
>> you get a number of different views on what it is and what it isn’t.
>> Most of the articles, in my opinion, take a very narrow view of POP
>> and try to fit it into the OOP model but with an Interface first
>> approach which, once again in my opinion, misses the larger view.
> Yes!
>> Once again I will explain this more in my next e-mail where I address
>> your question about what I mean when I say that POP is about so much
>> more than the protocol.
>> Jon
>>>> The winner is actually the programmer because we are not limited to
>>>> one programming paradigm.  We can choose the paradigm that fits our
>>>> needs.  Personally I have use POP in a number of projects and I
>>>> definitely prefer it to OOP or FP but I would not criticize anyone
>>>> that uses the other two because they are very valid paradigms that
>>>> have proven over time.
>>> -- 
>>> -Dave
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160307/12c11410/attachment.html>

More information about the swift-users mailing list