Fun with Swift

http://joearms.github.io/2016/01/04/fun-with-swift.html

by Turing_Machine • 11 years ago

220 109 11 years ago

joearms.github.io

mpweiher• 11 years ago

Above all it had a REPL and I could program outside Xcode (which I hate).

If that's the "above all", not sure what his beef is with Objective-C. You could always program outside of Xcode and various sorts of REPLs were/are available.

ben-schaaf• 11 years ago

The lack of proper syntax highlighting and long lines is making this really difficult to follow on mobile.

jld89• 11 years ago

It is actually generalized. Not only on mobile. Hard to read indeed but very interesting nonetheless.

e28eta2• 11 years ago

I think the author should do some more reading about Swift. He complains about a lack of inferred typing and pattern matching, two things which Swift does support. It's more limited than Haskell, but it's there.

I also disagree with his statement that Objective-C is better for writing an operating system.

He seems to conflate using Xcode with the built-in support it has for xibs to do UI layout. You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code.

e28eta2• 11 years ago

Replying to myself, because I thought about this a little more. I'm someone who's very excited about Swift. But I'm also interested in learning a variety of languages (and seeing their influences on Swift feeds my excitement).

It's easy to pick on specific mistakes in the article. However, what I think really bothered me is the criticisms of Swift that didn't show an understanding of why Swift is the way it is. And perhaps that's unfair to the author - who's just writing up his experiences.

I like seeing well reasoned criticisms. I dislike value judgements that don't seem to acknowledge the trade offs involved in all software engineering.

omaranto• 11 years ago

Does he actually say anything wrong about Swift's type inference? I only found a spot where he mentions you need to declare types, which I thought was true at least in some spots.

rubiquity• 11 years ago

The author is one of the creators of Erlang which is a language that takes pattern matching above and beyond what Swift does (as well as Standard ML/OCaml/etc).

allsystemsgo4• 11 years ago

You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code.

I don't understand why you would do your UI layout in code if you can avoid it. If someone ever joins my team or inherits my code base, they're now partly responsible for maintaining the UI. Xib's and storyboards help with maintainability, legibility, and drastically lower the number of lines of code. The author even says:

Find an example program that works then reduce lines until I can reduce no more making a minimal example that works - then understand every line

If you care about the line count, then why are you doing all your UI in code?

seivan3• 11 years ago

Well until Xcode 6 (I think). Neither xibs nore storyboards were indexable. Meaning if you wanted to find something related to your layout, you would had to search through xml. Also much easier to refactor typed code than xml ;)

cballard2• 11 years ago

Layout done in code:

- Is type-safe, which is verified at compile-time.

- Will break at compile-time if a breaking change is made.

- Can be null-safe, without having to use Optional for everything.

- Can do things iteratively.

- Can use constants, so that you can easily modify standard paddings and sizes globally with one change.

So those are some of the advantages of doing layout in code.

mahyarm3• 11 years ago

xibs are not mergable. Have 2-3 people working on the same xib, and it's a mess to merge. It needs to become human editable. That is the major reason why for most larger projects.

Also xib tooling can be a pain for complicated layouts.

masklinn9• 11 years ago

He complains about a lack of inferred typing and pattern matching, two things which Swift does support.

1. Swift only implements local type inference (which the user makes use of), languages like Haskell or MLs support global type inference. That is, Swift does not infer function types.

2. Swift's pattern-matching support is more limited than Haskell's or Erlang's[0] and function toplevels aren't pattern-matched whereas Haskell's or Erlang's are.

[0] notably, you can't use refutable patterns in Swift, while they're very common in Erlang, and by default only a limited number of type classes — tuples, enums, ranges and atoms IIRC — can be matched, you can't destructure an arbitrary structs by pattern matching. On the other hand, Swift's pattern-matching can be extended (by overriding ~=)

ridiculous_fish• 11 years ago

Isn't switch an example of refutable pattern matching in Swift? You can distinguish enums, and use where clauses:

    switch read(/* stuff */) {
    case 0:
        print("EOF")
    case let amt where amt > 0:
        print("Read \(amt)")
    default:
        print("Errored")
    }

The 'let amt where...' is a refutable pattern, isn't it?

rdtsc6• 11 years ago

two things which Swift does support

For some value of "support". If you mean compared to C, yes it has pattern matching. If you mean compared to what Haskell, Erlang or Elixir has, not as much.

The author is one of the creators of Erlang so from his point of view pattern matching is severely lacking.

I have used Erlang, Python, C#, C++, Java and yes, I though Python had pattern matching compared to Java. But then used Erlang and realized that Python doesn't have pattern matching ;-)

It is one of those things that once you use it, it is very easy to notice when it is lacking.

masklinn9• 11 years ago

yes, I though Python had pattern matching compared to Java.

Python doesn't have pattern matching at all though, and doesn't advertise such a feature. It has iterables unpacking.

hellofunk10• 11 years ago

Swift is widely marketed as a functional language

If that's true, those sources reporting that are wrong. Apple itself refers to it instead as a "protocol-oriented language" when it's not just saying "object-oriented".

Swift is definitely not a functional language in the way that it usually means, and Apple knows this, and any legit survey of languages wouldn't clump it together with much more functional languages. For example, this guy[0] knows what he is talking about.

Where Swift shines it is in the integratiion with the underlying Objective C frameworks on the Mac.
Swift is a good replacement for contexts in which Objective-C would be used.

Except when you try to do anything with OpenGL or a C-based API, like Core Audio. Swift is really lagging for "power programming" with these low-level APIs. It's great for beginners who use all the high-level frameworks (though "great" is a subjective term I don't really agree with for Swift), but a lot of people who really need to get stuff done on Apple's platform are not going whole-hog Swift.

If you’re coming form Erlang/Haskell world you’ll think Swift is verbose and a bit of a mess but if you’re coming from Objective-C you’ll think “Swift is concise and elegant”

I got to be honest, I still find I prefer Objective-C, because, it's essentially C. I can use my C structs and interfaces with zero problem. But in Swift, all C primitives are translated into Swift-only stuff, even integers!

And don't get me started with trying to use a C++ library with Swift, something that's smooth with Objective-C. Which is ironic since Swift itself is written in C++.

[0] http://robnapier.net/swift-is-not-functional

melling• 11 years ago

In your provided reference, the first sentence Rob writes:

"Ever since Swift came out, I keep seeing weird comments that Swift is a functional programming language"

Swift is often promoted as being "functional":

http://www.raywenderlich.com/114456/introduction-functional-...

In fact, I've tagged many articles as functional in my Swift resources:

http://www.h4labs.com/dev/ios/swift.html?q=functional&age=10...

Want to buy a book on functional programming in Swift?

https://www.objc.io/books/functional-swift/

hellofunk10• 11 years ago

Note that the objc.io book is more about building functional idioms from scratch so you can use swift in a functional way, rather than actually leveraging a strong functional core of the language. The fact remains that Swift is just not a functional language and attempts to categorize it as such are unrealistic.

seivan3• 11 years ago

On a WWDC video named something along the lines of "Value types in Swift" they explained that Apple is trying to get try middle ground between protocol oriented and functional. Same thing with mutability and immutability. They aren't pure anything because both ways have their purposes.

s73v3r• 11 years ago

People say a lot of things. Doesn't make them right.

robbyking• 11 years ago

Swift is a multi-paradigm language. In that Ray Wenderlich article you linked, he writes "This tutorial focuses on just one of these methodologies, FP (Functional Programming)"

mikeash11• 11 years ago

What is a "Swift-only" integer? Swift integers are just integers. They interoperate with C just fine.

Interacting with C APIs in Swift is pretty much as convenient as using them from C or Objective-C. Which is to say, it's kind of inconvenient compared to using a good Swift API, but you don't gain a benefit from using C or Objective-C instead.

The major exceptions to this are the inability to take a pointer to something before it's initialized (for example to use a local variable for an out-parameter) and the inability to declare arrays on the stack. The former just requires some "= 0" or similar, and the latter can be worked around without much difficulty using a Swift Array or just using malloc and free, at the expense of a bit of performance.

There is also a problem where Swift translates fixed-length arrays to tuples (because Swift has no concept of fixed-length arrays) which can be inconvenient, but this rarely comes up.

Maybe you're just not familiar with the facilities Swift provides for interacting with C APIs and are doing things in a more difficult way than is necessary.

It's absolutely true for C++ interfaces, of course, but Swift doesn't even try and never advertises C++ interop. For that, you have no choice but to use C++ or Objective-C++. But for plain C APIs, Swift does a great job.

hellofunk10• 11 years ago

What about stuff like this, these weird castings that pop up in Swift that you don't worry about in Objective-C when dealing with C APIs:

glBindBuffer(GLenum(GL_ARRAY_BUFFER), bufferIds[1])

glBufferData(GLenum(GL_ARRAY_BUFFER), sizeof(Float) * tcSize, tc, GLenum(GL_STATIC_DRAW))

That just looks silly to me.

hellofunk10• 11 years ago

I've read a number of articles like this one regarding the Integer protocol in Swift and the many different int types:

http://blog.krzyzanowskim.com/2015/03/01/swift_madness_of_ge...

I guess everyone's mileage varies, but I find it a bit strange.

fleitz3• 11 years ago

Interfaces which use the pattern:

  struct foo bar;
  foo_init(&bar);

Can be very annoying in swift, it does play nicely with CoreFoundation which does not use this pattern

nstj• 11 years ago

I actually find working with C in Swift to be far more pleasant than using C directly. The blog post by our friends at Apple on the subject -https://developer.apple.com/swift/blog/?id=6 - gives a pretty good background.

thejay• 11 years ago

For some reason reading the post gives me a deja vu of a win32 GUI programming tutorial :)

dguaraglia• 11 years ago

Hehe, must be all the HWNDs in the code :P

drivebywire• 11 years ago

For people who don't recognize the name, the author is one of the inventors of the Erlang programming language. Erlang is famous for its approach to mutability, concurrency, and error handling.

iraphael• 11 years ago

The closure f does not capture the value of i at the time when f is defined, changing i after f was defined make nonsense of the idea of a closure.

I have an incomplete understanding of functional programming. Are there other uses for closures (besides readability and practicality) that still work if they don't capture the value of i? If not, is this something someone should suggest as a change in swift-evolution?

wtetzner4• 11 years ago

The closure f does not capture the value of i at the time when f is defined, changing i after f was defined make nonsense of the idea of a closure.

Not sure why this "makes nonsense of the idea of a closure." You're closing over variables, not values. If you marked i using let instead of var, then you'd get the "preferred" behavior.

hellofunk10• 11 years ago

This underscores the notion that functional programming is ultimately about immutability, and all the idioms expected by a truly functional language are really a result of how it handles state more than anything. A closure is usually expected to close over values, and the idea of a "variable" doesn't really mean the same in a truly functional language, which is where all the confusion and the pain points stem from.

tel• 11 years ago

He's complaining about mutable state, essentially. The function `f` captures reference to `i` but does so transparently. One might expect that `f` would be free of side effects, but since `i` can be re-bound whenever this is not the case.

Essentially it comes down to the semantics of `=` whether it's declaration or assignment. Swift appears to choose it to be assignment. If I remember right you can declare things constant which would effect declaration only (sort of) but clearly there's an expectation that this happens all the time.

masklinn9• 11 years ago

He's complaining about mutable state

Bindings rather than state, the author has no issue with captured objects being mutable, only with the captured environment being mutable.

lyinsteve• 11 years ago

The author completely missed the point of named parameters. How am I supposed to know that the string argument of "make_window" is the title?

masklinn9• 11 years ago

The author completely missed the point of named parameters.

The author didn't miss the point of named parameters. At no point does the author even cover the point of named parameters. The author complains that:

1. they're inconsistent, all parameters but the first are named by default and named parameters are still positional (you can't reorder "named" parameters in the callsite)

2. making parameters purely positional is non-obvious and ugly

And he missed the part which takes the cake: Swift doesn't actually have named parameter, parameters 1+ are labelled (#1), and labels and names are independent, you can define this:

    func foo(a b: Int, c d: Int) { … }

which is called with a:c:, but the bindings are on b and d. You can also define this:

    func foo(a b: Int, _ d: Int) { … }

which is called as `foo(a:5, 7)` which while somewhat consistent is really garbage.

mikeash11• 11 years ago

In Swift terminology, a and c are "external names" while b and d are "local names." I don't see much of a difference between a "name" and a "label" here in any case.

I don't understand why the ability to set different external and local names is so bad. External names are part of the API, local names are part of the implementation. It often makes sense to make them the same, but there are case where you want them to be different, and what's wrong with that? It's ultimately no different from loading a parameter into a local variable of a different name and then operating on that local variable. Yes, you can use this facility to make ugly APIs, but you don't have to.

MCRed• 11 years ago

FWIW - This is Joe Armstrong, one of the creators of Erlang. Definitely an old-school REPL/functional guy, and I love seeing him playing around with swift.

Regarding GUIs and IDEs: I think interface builder is the best ever way to build UIs, far more fun and comprehensible than web development. I totally understand why Joe wants to control every line of code and do nothing in Xcode-- when things go wrong in the IDE they can be a pain to deal with.

For me, I think there's several common stages of Mac/iOS developer: 1. Newbie- needs Interface builder because GUIs are all so confusing and he doesn't yet know the API. 2. Control Freak -- knows enough (and spent enough time struggling with Interface Builder, because IB isn't a magic box and you do have to know how things are working under the hood, and the Newbie often struggles because of this).. and so he wants to avoid IB and do everything in code so he has absolute control. 3. Starting to see the light-- tired of tiresome pointless repetitive GUI code, back to Interface builder, but this time understanding the underlying parts of it, and having a lot more fun with IB 4. Enlightened-- uses Interface builder for most stuff, but knows when and where to drop down to GUI code and generally only does that in a highly leveraged way.

One of the things I find frustrating about web development is there is no interface builder (though some people have attempted to create them in the past, they always seem to abandon them, unfortunately.) So you're always stuck wit the frustration of constantly defining everything by hand-- when the reality is there's nothing that should stop web browsers from being able to handle auto-layout the way that iOS does.

Anyway, if you've rejected IB and are finding GUI code a PITA, try using IB in balance.

hellofunk10• 11 years ago

Your 4 stages are right on. I've been through all 4 and can say you hit the nail on the head.

And thanks for calling me "englightened." :)

lr• 11 years ago

"One of the things I find frustrating about web development is there is no interface builder"

There was, and Apple killed it. It was WebObjects Builder and it was a GUI for interacting with the components you wrote in code in XCode when doing WebObjects development. It was the web version of IB, and, in its day, it was awesome.

mamcx• 11 years ago

I think interface builder is the best ever way to build UIs

Do you have experience in other tools? Because a lot of people only know xcode/visual studio (maybe java) and think them have good GUI builders.

The best ever (and I have used A LOT) is the Delphi one. Very close? Visual FoxPro/Acces.

The rest are sad attempts at it ;)

coldtea2• 11 years ago

Which to my mind is horrendous. The closure f does not capture the value of i at the time when f is defined, changing i after f was defined make nonsense of the idea of a closure.

Of course it should change i after the closure was defined, since the closure doesn't copy but refer to that i.

Looks like a fully proper closure.

Which language does this differently?

hellofunk10• 11 years ago

The problem is that closures don't usually refer to mutable entities, and most functional programmers are used to an immutable language. The idea that a closure itself is mutated (its return value can change) just because something outside and separate of it mutated goes against the very heart of functional programming, and is not how functional languages behave at all.

john_butts• 11 years ago

This gets back to the point that Swift is not a functional language. By default, the closure is capturing an immutable reference - the fact that the value might change is implicit to the way you must think about programming in a non-functional language. The mechanism to capture a constant value is to declare it in in a capture list:

  var f = {[i] in print("hello I'm a callback and i =", i)}

masklinn9• 11 years ago

Which language does this differently?

Languages with immutable bindings (the author is one of the original designers and implementers of Erlang)

icebraining• 11 years ago

In fact, he expands on closures in an earlier post (about Elixir):

Proper closures should only contain pointers into immutable data (which is the case in Erlang) - no pointers into mutable data. If a closure contains a pointer into mutable data and you change the data later you break the closure. This means you can’t parallelize your program and even sequential code can contain weird errors.

http://joearms.github.io/2013/05/31/a-week-with-elixir.html

adrusi• 11 years ago

They don't do it differently, they simply avoid the question by not letting you change any binding ever. In languages that embrace immutable bindings but don't enforce them, like scheme, closures work exactly as the parent describes.

malisper• 11 years ago

He's not saying that closures over mutable variables is a bad thing in Swift. He is saying it's a bad idea in any language, even though most languages with closures allow it.

golergka• 11 years ago

I see how programmers can mistake mutable closure references for immutable, but if we imagine that this confusion is solved somehow (for example, closures copy values by defualt and reference only with a special keyword), how is it bad?

raffomania• 11 years ago

This behavior is one of the reasons not to call JS a 'functional' language, IMHO.

qwertyuiop9249• 11 years ago

Well then scheme isn't one either. But then, scheme isn't one. And javascript is just a language in which the functional paradigm is common. it's a multi-paradigm language. Anybody who says otherwise doesn't know what their talking about.

mikeash11• 11 years ago

Objective-C does it differently by default:

    int x = 0;
    void (^block)(void) = ^{ NSLog(@"%d", x); };
    x++;
    block();

This will log 0, not 1. If you want to capture by reference rather than by value, you add __block to the declaration of x.

For a lot of people coming to Swift from Objective-C, this is a surprising change, especially if Objective-C was their first language with closures.

qwertyuiop9249• 11 years ago

That's a block, not a closure. It's still an anonymous function, but the semantics are slightly odd, and derived from Smalltalk, probably altered some.

tarentel• 11 years ago

This is only surprising because of the ambiguity of value types in certain cases in Swift. If you passed it to a function and mutated it then it would work as your example. I'm still not sure why they made it work this way for closures. Using reference types closures and blocks are more or less the same.

rdtsc6• 11 years ago

Of course it should change i after the closure was defined, since the closure doesn't copy but refer to that i.

Well it should not allow it and make ia clone / copy-on-write thing /etc. Calling that a closure sounds broken. Just like Joe points out.

Which language does this differently?

Haskell, Elixir, OCaml, Erlang

qwertyuiop9249• 11 years ago

No, those languages just don't allow you to modify state. In non-functional languages like swift, you can modify state, and closures respond to that.

What I think a lot of people fail to understand is that a closure is not a special object, with magical powers, but a direct consequence of lexical scoping: closures just follow the lexical scope rules, even if their lexical scope isn't within the current dynamic scope. If a variable within the closure's lexical scope changes, the closure won't keep the value the same. Here's an example of these semantics in C:

  int global = 4;
  void oh_noes(){
    printf("%d", global);
  }
  global++;
  oh_noes(); //prints 5

If somebody complained that the function oh_noes should print 4 in this example, you'd think they were insane. Closures actually work in exactly the same way.

losvedir• 11 years ago

It's a bit weird. I don't think Joe would have an issue with mutating the closed over variable, but having the closure just be the binding rather than the value, and then being able to rebind it to something else seems brittle.

Which language does this differently?

Rust does it this way but in a less error prone way due to its sophisticated ownership tracking. If you close over a variable in the environment, it gives the ownership to the closure and you can't then rebind it outside.

musha68k• 11 years ago

I'm currently working on a project which makes me jump between Swift and Erlang/Elixir on a regular basis. I actually enjoy Swift's OCD typing, particularly in exchange over not having to maintain those mind-numbingly redundant header files any more.

All in all I feel as if Steve Jobs would have been proud of what the Swift team has accomplished - lots of "great artists steal" in the functional programming department while still being disciplined enough to not go overboard with features and staying true to Apple's design culture in general.

That said the lack of pattern matching really is something I've come to miss too and Elixir application code in general feels much more elegant and almost effortless to read and write in comparison to Swift.

Playgrounds are fun and all but IMHO Joe is very much right - all the cruft, the arcane NeXT "magic spells" as well as the mouse-heavy Xcode dependence should make way for new ways to do things. The kids "ain't stupid" I mean young programmers probably all grow up with some command-line fu, essentially making Unix the new lingua-franca (besides Javascript;) so why not embrace OSX/Darwin and go for something more along the lines of how RubyMotion does things?

Whipping up a simple GUI with a couple of action functions really should come with the least amount of needlessly distracting development abstractions.

It probably would also mean less Apple developer time wasted on the next potentially buggy Xcode feature..

Less is more, but again Apple is getting there, especially now that we might be on a path to more complementary open-source development tooling - so to me, doing Swift with Xcode is super productive and fun already!

BuckRogers• 11 years ago

I agree, once you step outside the bounds of "text only" you bring on a whole mess of complexity. I've always disliked programming in Eclipse or VS, it just feels wrong compared to a nice simple .py file or whatever you're working with that can be used with any editor you want.

It seems like language complexity brought on IDEs, rather than anything else. They tried to fix the verbosity of C++ and in turn, Java, by creating new IDEs rather than a newer higher level language.

ldesegur• 11 years ago

Swift feels very immature in many areas. For example, Swift fails with generics out of most ordinary cases. Today, you still can't restrict protocol conformance (inheritance clause) to a type-constrained extension. That's a big issue with arrays. A struct wrapper is the go-to solution for many things where Swift generics break down and it's not the best or more elegant way to resolve its limitations. Many hopes for Swift 3.0 but I doubt they'll fix those.

Fun with Swift

Related Stories