Swift impressions

http://www.evanmiller.org/swift-impressions.html

by gmac • 12 years ago

78 75 12 years ago

gmac• 12 years ago

I'm with him on the arcane rules about Array copying — IIRC, when you modify them such as to change the length but not otherwise.

Someone5• 12 years ago

I do not understand that, either. Also, I find it weird that dictionaries are value types. If I started programming in Swift, I think I would soon have a generic class named 'Dict' that has a single field storing a Dictionary and the same interface as the Dictionary struct.

Does anybody know what is the reason they chose those non-standard behavior for the standard containers?

lohankin• 12 years ago

My guess is that they want you to declare map/array arguments as "inout" to be able to add/change things so that the changes are visible by caller. It might not be a bad idea after all.

m_mueller• 12 years ago

Isn't that such that you can declare a dictionary or array as constant by using 'let' in the declaration? I think the designers wanted to avoid complicated annotations for constant the way it works in C++. Being able to use 'let' also seems to make collections available for matching in case statements. I recommend watching this[1] tutorial - the way switch/case works in Swift was really impressive to me.

[1] http://fitacular.com/blog/swift/2014/06/08/apple-ios-tutoria...

josephlord• 12 years ago

Note also the fact that constant arrays (declared with let) are only constant in length. I've made some speculation and a suggestion here: http://blog.human-friendly.com/swift-arrays-too-swift-and-fl...

mercurial3• 12 years ago

I'd be curious to get a summary of what Swift has that is not a mix of traditional OO and ML-family features.

AlexanderDhoore• 12 years ago

What other language families are there, apart from C and ML languages? Lisp, maybe? Maybe dataflow or logic programming?

Dewie• 12 years ago

Pascal?

pjmlp3• 12 years ago

Algol family, which C definitely isn't part of.

It is composed by Mesa, Cedar, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada, Spark, ParaSail, ...

Someone5• 12 years ago

If you zoom out far enough, few (for example, from a few miles away with my eyes almost closed, I would put Algol and C in the same family: procedural and with block scoping).

There are quite a few distinctly other languages, though. To name a few: APL, COBOL, Forth, sed, Snobol.

jamra• 12 years ago

You have some nice functional stuff. You can define a function on a primitive type like an integer. This enables you to have code like 400.times(doX). doX is a function. Functions as first class citizens are nice.

If you have a function as a final argument, you can change this: something(a, b, { }) to something(a, b) { }. Basically, you just put your anonymous function on the outside of the parenthesis.

I think the book's example was something along the lines of sort(arr) { $1 > $2 }. I think that $1 is some kind of default specifier for the first param and $2 for the second, but I'm not sure.

nextstep• 12 years ago

You're correct about the $1 syntax representing parameters, but the parameter indices start at 0: sort(arr) { $0 > $1 }

tomp• 12 years ago

Well, the problem with C++/Java and the ML language families is that they are quite incompatible, so it's not really trivial to mix them. Many languages have tried, most recent languages really. Rust is C with ADTs or ML without garbage collection (not yet sure how closures will turn out), Scala is Java with first-class functions and ADTs, Java and C# are absorbing more and more features from ML, ...

Swift is just another attempt to mix the two, quite a successful one IMO. They kept some warts, probably to maintain binary compatibility with Obj-C, but otherwise I think it's a huge improvement over Java-style languages.

One particular pain point between Java-style and ML-style languages are generics; Java and C# have a common object protocol and thus allow a top type, Object, and run-time type information. So, they must decide whether generics/type parameters are only relevant at compile-time (Java) or are kept at run-time (C#). ML avoids this issue by not having any runtime type information (and no type-testing construct). I haven't yet found where Swift stands, but it's a hard problem to solve.

austinz2• 12 years ago

Swift doesn't have a designated base class like Java, C#, or Objective-C's NSObject. It seems, though, that there are a bunch of interop considerations which means that you might need your Swift classes to inherit from NSObject for them to work properly with Cocoa code.

Swift also doesn't perform type erasure. You can do something like the following, as I believe is possible in C#:

  struct SquareMatrix<T> {
    let dimension: Int
    var backingArray: Array<T>

    init(dimension d: Int, initialValue: T) {
      dimension = d
      backingArray = T[](count:d*d, repeatedValue:initialValue)
    }

    subscript(row: Int, col: Int) -> T {
      get {
        return backingArray[row*dimension + col]
      }
      set {
        backingArray[row*dimension + col] = newValue
      }
    }
  }

spicyj• 12 years ago

Override functions must use the `override` keyword. Now when you rename the superclass's function, all the subclass functions fail to compile because they're not overriding anything. Why did no one think of this before?

As I understand it, Java has a similar `@Override` annotation:

http://stackoverflow.com/q/94361/49485

derekerdmann• 12 years ago

C# also includes compiler checks to make sure you're explicitly overriding methods correctly: http://msdn.microsoft.com/en-us/library/ebca9ah3.aspx

skwirl• 12 years ago

C# takes it even further by not allowing you to override methods unless they were marked as overridable in the base class with the "virtual" keyword.

evmar• 12 years ago

C++ also, though you need to wrap it in a macro to work on older compilers.

https://code.google.com/p/chromium/codesearch#chromium/src/b...

pjmlp3• 12 years ago

Eiffel, Object Pascal, Modula-3, Component Pascal and many others do as well.

I guess the author is not well versed in programming languages history.

alayne2• 12 years ago

I read the article as being in the context of Objective-C bugs that were solved by Swift.

coldtea• 12 years ago

Yes, he probably spends his time actually coding stuff in just one or two languages.

fatihpense• 12 years ago

I think he means, "Why did no one think of this before" in Obj-C

ninkendo• 12 years ago

Java's @Override is not only optional, but fails to address an important use case: when you don't want to override anything with your method, and then the base class has a method added to it with the same name as yours. (Or if you simply didn't know that the base class had that method.) Swift will make sure you don't inadvertently override base class functionality by requiring you to use it.

cromwellian9• 12 years ago

In Java, you'd just add a 'final' keyword to the base method and you'd get a compile time error if someone accidentally tried to override it.

If you want the equivalent of !@Override, a) you can do it with Java8 annotation types and a checker or b) you can just declare the method private.

I'm sure Swift's version also fails to address all of the edge cases people might want to catch. No type system can be complete and catch every use case.

cromwellian9• 12 years ago

First of all, "no garbage collection" Technically, referencing counting is garbage collection, it's automatic memory management by definition.

Is ARC really a win over non-refcounted GC + escape analysis? Full manual control over stack vs heap allocations and lifetime, I get, especially for games. But reference counting is not deterministic, and can also generate pauses.

@Override has been in Java since Java 5.

lxcid3• 12 years ago

ARC are less likely to get paused as memory release are amortised rather than gather and swept.

Also, LLVM static analyze is so good at figuring out your code path that it could effectively retain and release your memory for you.

Cyclic reference is its only flaw but its something that can easily solved through programmer awareness.

rayiner• 12 years ago

Maybe not so much: https://news.ycombinator.com/item?id=7849631

tormeh• 12 years ago

Can't cyclic reference be fixed by a garbage compiler occasionally cleaning up those things? I think that's how Python does it, not that Python is a beacon of performance, but it's possible.

cromwellian9• 12 years ago

What LLVM static analysis can be done to figure out the lifecycle of objects also applies to other GC algorithms.

ARC may be less likely to get memory paused on release, but ARC doesn't compact free memory, and therefore fragmentation can cause object allocations (malloc) to become more expensive, possibly leading to pauses.

If you use non-copying GC that doesn't compact (ARC doesn't compact), then there are low pause GC algorithms out there that give pretty good bounds (e.g. 5ms pause).

I'd like to see actual benchmarks of both ARC and say, mark-and-sweep on a mobile device rather than speculation and opinion, and both benchmarks must get the same static compilation treatment. That is, if escape analysis tells you that the lifetime of the object is bounded by the current stack frame, then allocate it on the stack, and don't penalize the non-reference-counted GC by allocating 100% of everything on the heap.

pjmlp3• 12 years ago

@Override has been in Java since Java 5.

I hate how they didn't make a keyword out of it, even if it meant breaking code.

kzrdude• 12 years ago

It's boring to discuss if we can't make distinctions. Linear types are also reference counted; the reference count is always either 0 or 1 and it can be computed statically.

cromwellian9• 12 years ago

Sure, but use appropriate terminology. Automatic memory management has been synonymous with garbage collection for decades. ARC is a form of AMM/GC. So don't say Objective-C+ARC isn't garbage collection, because it is.

The proper distinction would be between local reference counting and GC at the time of release, and global heap traversal from roots.

alayne2• 12 years ago

@Override is optional in Java. All it does is validate that a superclass method with the same signature exists. It doesn't work in the other direction.

This doesn't compile with Swift:

    class A {
        func foo() {
        }
    }

    class B : A {
        func foo() { 
        }
    }

cromwellian9• 12 years ago

In Java, you make the function part of an interface to achieve that:

interface Foo { void foo(); }

class A implements Foo { ... } class B extends A { ... }

If someone renames Foo then A and B fails to compile. If you don't want to use an interface, you do it like this:

class A { abstract void foo(); }

class B { void foo() { ... } }

Yes, it's not exactly equivalent but, this is a rather contrived case that never happens in Java because

a) almost everyone uses @Override because IDEs add it automatically b) Java programmers don't refactor by using VI and editing a base class's method names. An IDE like IntelliJ IDE does all the work automatically. c) if you really want to ensure that a class implements a certain interface, you use a Java interface to enforce it.

This swift feature is interesting, but it's not really anything to sell the language.

guelo• 12 years ago

That's why one of the first things I do when configuring my Java IDE is tell it to mark missing @Override as a compiler error.

curveship• 12 years ago

In C#, the compiler issues a warning unless you declare the shadowing method with a 'new' keyword.

Gigablah• 12 years ago

Hack also has <<Override>>:

http://docs.hhvm.com/manual/en/hack.overrideattribute.php

eco• 12 years ago

Yeah, D has it too. It's a good feature.

altyus2• 12 years ago

That's kind of irrelevant. The only thing that really matters since swift is built to natively support Cocoa, is was this possible in Objective-C (and to a lesser extent C and C++).

afternooner• 12 years ago

Okay, can someone who understands this explain it a little better. My understanding is that ARC (or automatic reference counting) wasn't garbage collection because there isn't any garbage collection. I had thought that ARC was a compiler optimization that would analyze your code and add the deconstructor code while compiling based off some possible usage graph or whatnot. ARC therefore is not garbage collection. Yes, it's memory management, but to link the two as the same is wholly inaccurate. Please chime in to let me know how wrong I am.

chrisseaton• 12 years ago

The canonical text on garbage collection by probably the most respected person in the field considers reference counting (automatic or otherwise) to be GC (http://gchandbook.org/contents.html). I know that's appealing to authority, but what else can you use to prove the definition of a term? Also see [1], which argues these algorithms are all the same thing anyway.

[1] D. F. Bacon, P. Cheng, and V. T. Rajan, “A Unified Theory of Garbage Collection,” presented at the Proceedings of the 19th Conference on Object-Oriented Programming, Systems, Languages & Applications (OOPSLA), 2004.

ohazi• 12 years ago

This is not how ARC works. ARC keeps a count (at runtime) of the number of references to dynamically allocated objects. Every time you create a new reference to an object, the count is incremented, and every time a reference goes out of scope, the count is decremented. When the count reaches zero, the memory is either freed immediately or marked as free-able for later.

Your bit about compile-time code analysis to automatically insert the cleanup code when data is no longer reachable is actually pretty similar to what Rust does today with owned pointers. The downside is that this doesn't work with "normal" code -- you need certain annotations for the compiler to be able to perform this task correctly. In Rust this is done via region pointers (lifetime parameters) and borrow checking.

ajanuary• 12 years ago

Before ARC they used manual reference counting. At runtime each object has a count of how many things have declared they have a reference to it. You can increment that count by doing [obj retain] whenever you know you're keeping a reference to it that will outlive the stack frame. When you're done with the object you can do [obj release] to decrement the counter. When the counter hits zero, the memory for the object can be freed (I don't actually know if it's done immediately or added to a list of objects to free later).

What the automatic part of ARC does is, at compile time, analyse the code and automatically add the retain and release messages. If it determines the reference will outlive the stack frame, it adds a retain message. if it determines the reference can no longer be dereferenced (maybe because another object reference is assigned to that variable) it adds a release message.

The runtime characteristics are the same as ARC, it just means the programmer no longer needs to work out where to add the retain and release messages (though they still need to think about reference cycles).

chrismonsanto• 12 years ago

First of all, "no garbage collection" Technically, referencing counting is garbage collection, it's automatic memory management by definition.

Thanks for making this post, I have been meaning to say something similar for a while now. And, re: one of your other posts in this thread, the GC handbook is excellent. One of my favorite textbooks.

What most people on this site call "garbage collection" would be more accurately called "tracing garbage collection."

lxcid3• 12 years ago

Swift seems to be a very pragmatic language. It borrow and learn heavily from other languages, but it doesn't try to be promise anything big. It just introduce opinionated defaults which is safe and tends to be at least 80% of the implementor's intend, while providing alternative for the 20%.

An example is the switch case fall through behaviour of C. In Swift, by default, switch case no longer fall through, but if you need that behaviour, you can always add fallthrough keyword at the end.

When you think about the above behaviour, it seems so much more natural, and wonder why we have been keeping ourselves bitten by this C language construct and developing muscle memory to prevent it by having break, sometimes with a scope (All cases in a switch scare the same scope within C switch, if I don't remember wrongly).

Part of the switch example is solved in other languages (default intends and scoping), of course. But the subtlety of the fallthrough keyword gave me a strong impression. It felt that it should always be a opt-in all these while, rather than an opt-out as it have always been.

With my limited command of english, I feels that I would do it little justice to the language trying to explains some of its concepts like optionals & mutability hints. Some of these concepts only modify the existing solution only so slightly, but meaningful enough to be impactful.

It also doesn't take a stance in the OO and functional debates. It is both OO and functional. Staying as pragmatic as possible.

Finally, Swift is like a wolf hiding under the sheep's skin. Its a very very strongly typed language. It is very specific about it type. But half the time, you can ignore the type and write it like python or ruby. The magic was type inference, its kinda weird but I like that.

You can almost feel that Chris Lattner might have felt he is reaching the point of diminishing return while optimising LLVM for Objective-C. after all, this is a very old language. He done a great job all these while with LLVM but sometimes, the problem is something deeper. Swift is kinda like Objective-C 3.0 without the backward compatibility.

(P.S. Objective-C is my favourite language before Swift)

If programming language is a sword, Swift is just another sword, albeit one that's very sharp.

xkarga002• 12 years ago

Go already has the same switch behavior (plus the fallthrough keyword) and is very specific about its types while having type inference.

altyus2• 12 years ago

haha these answers are cracking me up. Who cares? Do people develop iPhone apps using Go? Swift never claimed to invent new paradigms that didn't exist in other languages, it simply brought them to Cocoa.

lxcid3• 12 years ago

Thanks! I didn't know that. Its truly interesting that many of our languages is evolving and converging.

seiji• 12 years ago

Anybody interested in an ebook about using all of Swift's strict typing features for better app development?

I may be in the process of writing one of those. It may be up to 100 pages so far with only a chapter or two remaining. It may be available for release in a day or two.

uptown• 12 years ago

I may be. Maybe.

Twisol• 12 years ago

Definitely. I think that would be fantastic.

foobarraboof• 12 years ago

wow! almost like C# from, what, 10 years ago?

sitharus3• 12 years ago

Except with pattern matching, built-in immutability, extensible classes, curried function and tagged unions.

More like F# 2.0 in feature set.

flym4n• 12 years ago

At its core, the language is designed to eliminate bugs, but not in the academic way that, say, Haskell eliminates bugs by preventing normal people from writing code in it

Shots fired

klickverbot• 12 years ago

D (http://dlang.org) has had mandatory override for a long time.

Swift impressions

Related Stories