
Swift Snares and How to Avoid Them - triceam
https://developer.ibm.com/swift/2016/01/27/seven-swift-snares-how-to-avoid-them/
======
stcredzero
_bringing in more modern paradigms such as functional programming and richer
type-checking than the Smalltalk-inspired pure object-oriented model of
Objective-C._

One thing I noticed while using Smalltalk: Large swathes of the Class Library
were "pretty close" to functional, in that there were very few side effects.
Because the debugger was so powerful, you could use it edit a method and "go
back in time" to replay execution with the new version. My theory is that, as
a result, a kind of social pressure against side effects developed, because
introducing side effects made fellow programmers annoyed at you while using
that wonderful debugger.

I wonder if there are other social mechanisms for getting to such a desirable
state, like having very few side effects? (Other than functional paradigm
hipsterism.)

~~~
danharaj
ML-like and Lisp-like languages tend not to be pure. There are mainly 3 kinds
of _pure_ functional programming languages: theorem provers, research
languages, and languages descended from Miranda. Both sides of the purity
design spectrum are influential, popular, and used in industry. So i don't
think it's "hipsterism" that explains why purity has been successful in
certain functional programming languages.

The research languages are mostly shaped by the idiosyncrasies of the
researchers who developed them. The theorem provers are pure functional
because no one actually wants to run the programs they write. This leaves
Miranda-style languages.

Miranda was pure for design reasons: Miranda was also a lazy language. Having
unrestricted side effects in a lazy language is almost completely unworkable.
This tension between side effects and laziness 'protects' lazy languages from
giving into the siren call of side effects as Simon Peyton Jones puts it.
Without laziness, they often give in.

So between your example and mine, it seems that some _technical_ capability
enabled by purity is the primary motivator for a continued culture of purity.
With Miranda, it was laziness that required purity. The inference is that
those languages became popular because laziness was useful enough to create a
community in the first place: no culture of purity without community of users.
Smalltalk's development environment was a similar kind of highly valuable and
distinguishing feature.

The abstract notion that purity is better for developers doesn't carry enough
value. It's only when it's translated into concrete capabilities that it
starts being considered.

------
cellularmitosis
Strange, this bullet point appears in the summary but doesn't appear anywhere
else in the article:

    
    
      Avoid assigning the result of an expression with side-effects to left-hand-side with optional chaining

~~~
gilgoomesh
Yup, looks like an editing accident.

In any case, you can probably guess what it was about. Something along the
lines of:

    
    
        var z = nil
        let x = y?.getResult(&z)
    

will z be changed?

~~~
senderpath
Sorry; editing mishap, yes. Here's the missing example:

class Holder { var x = 0 } var n = 1 var h: Holder? = ... h?.x = n++ n // 1 or
2?

~~~
senderpath
PS: We have corrected the editing glitch and restored the missing section.
Thanks for catching it.

------
adajos
Hope the dynamic/static dispatch issues around protocol extensions get sorted
out--the current state is pretty lousy.

