Smashing Swift

http://nomothetis.svbtle.com/smashing-swift

by afthonos • 12 years ago

281 143 12 years ago

nomothetis.svbtle.com

noobermin• 12 years ago

Just to point out, the last two sound like it's due to the current implementation (compiler) being new, so it isn't so upsetting at all.

Now, not supporting functors is odd, though.

afthonos6• 12 years ago

Yeah, that's why I said the crashes gave me hope. It seems they are trying to support those use cases, but haven't worked out the kinks. I'm totally fine with that.

pohl5• 12 years ago

Why is it odd? Is there a historical precedent for some other language exposing higher kinded types this early in the lifecycle? (Prior to 1.0, that is?)

Ωmega, maybe? Is that what we're expecting of the new "normal" already?

sparkie• 12 years ago

It's not odd that Haskell didn't have them in 1.0, because they were not conceptualized until '93[1] after the Haskell report has been published in '90. They made it into the Haskell report 1.3 ('96)[2].

We should not be comparing the development of languages now to 20 years ago - there is an enormous amount we have learned, and these insights should be fundamental considerations when designing a new language. You can't just "tack" things onto an existing language and expect it to be elegant - tacking on leads to huge languages like C++.

And yes, we should expect it as "normal" for new languages, because it is what people have come to expect to have available - although some implementations leave a lot to be desired.

If we consider how C# implements Functors for example, we see that it requires special language support, where the compiler essentially pattern matches over your code, looking for a method named "Select", with a specific signature taking a generic type and a func. This implementation completely misses the point that Functors themselves, while useful, are not special - they are a specialization of a more general concept we have - typeclasses and higher-kinded polymorphism. C# also adds the ability to create Monads, Foldable, Comonads etc, using similar patterns - but you can't create your own typeclasses, and are left to the language designers to add a desired feature.

The decision to add them onto C# like this was made not without knowledge of this, but out of consideration of working with the existing language, which was designed without their consideration, hence, why they're a pretty ugly design compared to the simplicity of Haskell's implementation.

[1] http://www.cs.tufts.edu/comp/150GIT/archive/mark-jones/fpca9... [2]:http://research.microsoft.com/en-us/um/people/simonpj/papers...

stefantalpalaru• 12 years ago

I love what the compiler crashes let me hope it will do

These rose-colored glasses are getting ridiculous.

andybak• 12 years ago

By my reading the author made that statement, not naively, but with full awareness of it's slightly ridiculous nature. I think that whooshing sound was their joke going right over your head.

afthonos6• 12 years ago

Author here. To be fully honest, it's somewhere between the two. Yes, I'm aware of the irony of the statement. But what I failed to make clear in the post is that the code in the last two examples passes the type checker. Where it fails is at the intermediate representation stage. So the grammar of the language supports the constructs but the backend hasn't caught up yet.

It's possible, of course, that Apple will modify the grammar to make these use cases impossible. But I would be very surprised. I can't blame anyone for accusing me of rose-tinted glasses until we know for sure, though.

rsynnott5• 12 years ago

An early beta compiler crashes! Oh, noes, Apple is doomed!

I think the point here is that if the compiler crashes, that implies that it is trying to do the thing, as opposed to saying "No, filthy programmer, I will not permit you to do that thing."

dirtyaura2• 12 years ago

I've had very similar experience: I try to port non-trivial, but still rather simple functional code, for example containing a couple of nested closures, and the compiler crashes. And it seems that the Xcode playground, the command line compiler and REPL all behave a bit differently. In one case playground works, but REPL crashes, in another, compiler works, REPL has trouble of figuring out types.

I have absolutely no experience on implementing compilers, but for a layman these inconsistencies seems very odd.

danabramov2• 12 years ago

Microsoft's work on C# compiler (Roslyn) is amazing: they offer compiler-as-a-library so the IDE, plugins and debugger use the same backend as the compiler itself. I wish at some point Apple could adopt a similar approach.

pohl5• 12 years ago

That's basically what drove the design of clang. No doubt the approach with swift will be similar.

coldtea3• 12 years ago

Hmm, Apple went there before Roslyn with Clang/LLVM (whose creator is the designer of Swift and works for Apple).

The idea behind LLVM was to have the various compiler stages and tooling be re-usable and plugin like, unlike the monolithic design GCC had.

And Apple already uses the came "compiler-as-a-library" approach, even for Objective-C, to implement: the compiler, the syntax highlight, AST-based auto-completion, debugging and error fix suggestions and other stuff.

I'm pretty sure that the case with Swift is the same. It's just that it's not stable yet, so you can get crashes at various stages of all those pipelines.

anko• 12 years ago

Check out LLVM (http://llvm.org)

Alphasite_• 12 years ago

I'm pretty sure thats what they've always done, at least for the time they've used LLVM.

leorocky3• 12 years ago

I don't understand what a functor is or why an array is a functor. Can anyone please explain? I did the wikipedia article for category theory and I read some stack overflow questions and I'm not sure I understand why an array is a functor. It seems some languages have their own meaning for what a "functor" is, confusing the issue.

My initial guess is that a functor is just sort of like a function that casts or does something like return an interface type from a type that implements the interface or a base class. Is that right? I still don't understand why an array is a functor though, I'd imagine it would at least have to be a function?

Edit:

Actually I think he's talking about Haskell's version of an iterable, and it would then make sense to call an array a functor.

https://en.wikibooks.org/wiki/Haskell/The_Functor_class

Why is that called a functor instead of an iterable or enumerable though?

JoshTriplett• 12 years ago

The name "Functor" can be confusing; it's a thing you apply a function to, not a function itself.

A Functor is a type t parameterized by some other type a, such that if you have a function from type a to type b, you can apply that function to a t of a and get a t of b.

Most commonly, a functor will be a container of values of type a, and the mapping consists of applying the function to each value, resulting in a container of values of type b.

Other common functors include a computation that returns type a (use composition to apply the function to the result to get a computation that returns type b), or a possibly null pointer to type a (map null to null, map pointer to a to pointer to b).

twic4• 12 years ago

In an alternate universe where functional programming was invented by programmers rather than mathematicians, map would probably be called something like convertWith and a functor would probably be called something like a convertible.

If you think of a function as being a way of converting from one kind of thing to another, then a functor is an object which has a number of things which you can convert to some other kind (a number which may be one or zero), using a method of your choice, and map is the name of the method you use to do that.

afthonos6• 12 years ago

Let's begin with the array. Imagine I have an array of characters:

var a = ['a', 'b', 'c']

I'd like instead to have the index of their position in the alphabet. That's another array of the same length that would look like this:

var i = [0, 1, 2]

To each element in a, there corresponds an element i, at the same index. And the operation we use is the same for each element:

f('a') = 0

f('b') = 1

f('c') = 2

But we could also want an array that gives us the next letter in the alphabet, like so:

var n = ['b', 'c', 'd']

Here the function is:

g('a') = 'b'

g('b') = 'c'

g('c') = 'd'

But we're very much doing the same thing. We call it mapping. So Arrays in Swift have a map function defined that works like this:

var i2 = a.map(f)

We're passing the function to apply to each member, and we get an array back, of the same length, with the result of doing so.

A functor is a generalization of that concept. It takes a type parametrized by another type, say Box<V> and a function from the parametrized type to another type, say f:V -> W. Then, according to rules that are specific to Box, if you map f over Box<V>, you'll get a Box<W> out.

The key is that exactly how a Box<V> becomes a Box<W> is up to Box.

orbifold2• 12 years ago

More precisely it is an endofunctor in the category whose objects are Swift types and morphisms are functions between Swift types. All this really means is that given a Swift type, say Int or String, there are Arrays of Int or String, and given a function like showInt(a : Int) : String, a functor gives you a function from an Array of Int to an Array of String (in this case it would just apply showInt to each element of the Array and the result would be the Array of String) in such a way that if you have two functions (to keep with the example, say toUppercase(s : String) : String, the function you get by applying the functor to the composition (toUppercase . showInt) is the same as the composition of functions gotten from the application of the functor to the individual functions. In addition it is required that the identity function is mapped to the identity function.

muaddirac• 12 years ago

Thank you for this. I find explanations that eschew category theory bizarre, this really cleared things up for me (having spent a lot of time with functors mathematically, and almost no time with them in a programming context).

tel• 12 years ago

If something is Iterable, it's a Functor, but not the other way around. Iterable implies there's an order to the elements, for instance. It also implies that you could get ahold of the elements if you chose.

Types which are Functors may have orders and may provide access to the elements, but the Functor interface does not provide those means. This allows you to instantitate more restrictive types. For instance (in Haskell notation)

    data Pretend a = Pretend

is a data type with only one element (`Pretend`) that pretends to be a container. Consider the two types

    Array Int
    Pretend Int

You can still consider Pretend to be a Functor (the mapping function is just a no-op) but it certainly isn't iterable.

In Haskell, Iterable is called Foldable and effectively is the following interface

    instance Foldable c where
      toList :: c a -> [a]

but `Foldable` is used because typically instead of converting it to a list you want to fold over the elements

      fold :: Foldable c => (a -> b -> b) -> b -> c a -> b

Dewie6• 12 years ago

Why is that called a functor instead of an iterable or enumerable though?

Probably because 1) it is inspired by category theory rather than some interface/signature from another programming language 2) "Iterable"/"Enumerable" might be misleading.

2): It might make sense for things like arrays, where you can think of the function (fmap) as enumerating/iterating over the array and then, for each value in the array, uses the supplied function on it. But Functors aren't just things that you can iterate over; functions themselves are functors, and function composition is fmap. But how does the iteration-intuition make sense in this case? Other functors are more a kind of "box" than a collection that can be iterated over (for example: the Option/Maybe type). Sure, you can say that you can implement fmap on Maybe by iterating over the data that it holds, namely the single data that it holds, but that doesn't really say much.

wting• 12 years ago

A functor is a thing that can be mapped over. For example:

    map abs [-1, 2, 3] => [1, 2, 3]

Arrays are the simplest example, but it looks like an iterable. However functors retain shape whereas iterables don't. For example if we had a tree (represented visually):

    oak = -1
          / \
         2   3

If we used oak as an iterable, we would lose the structure of the tree:

    map abs iter(oak) => [1, 2, 3]

However if tree belongs to the functor typeclass (i.e. implements functor interface), then:

    map abs oak => 1
                  / \
                 2   3

The alternatives to functors are:

1. mutate the existing data structure

2. copy a new one and then mutate (two passes)

3. create a new one while mutating (one pass, increased complexity / bugs)

leorocky3• 12 years ago

I get it now, thank you for this great explanation, and all the other explanations as well. I think it warrants its own wikipedia page.

dscrd• 12 years ago

However functors retain shape whereas iterables don't.

Wow. Such a simple sentence yet this is the first time I have read it, and it makes the concept much more clear than hundreds of articles before did. Thank you!

I wish all FP features would be explained so simply.

ScottBurson• 12 years ago

The term "functor" is badly overloaded in general -- almost every language that uses the term has its own definition. In C++, it's an object that can be called as a function (by virtue of defining 'operator()') [0]. In Prolog, it's the head and arity of a term [1]. In ML, it's a function from structures to structures [2].

[0] http://www.stanford.edu/class/cs106l/course-reader/Ch13_Func...

[1] http://www.swi-prolog.org/pldoc/man?predicate=functor/3

[2] http://en.wikipedia.org/wiki/Standard_ML#Module_system

archgrove3• 12 years ago

Compiler bugs really don't worry me - despite the name, this is is really an alpha release. However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0). It seems like a deliberate design choice, but one I'm not really sure about.

The primary vibe I'm getting from Swift is pragmatism. They had various red lines to follow: must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc. This had led to a language which, despite being at version 0.1, has a fair few oddities and warts already. For example, the "almost but not quite immutable" arrays seem to be an artefact of absolutely wanting array performance to be equal to standard C. Typealiases vs parametric protocols seem to be a desire to have as much type information fixed as soon as possible.

It seems that rather than design a language where they might not have solutions for their red lines up front, they've designed a language where they can provide them. Rather than make theoretically "better" choices the compiler can't deliver perfectly in V1, but can in V4 or 5, they've gone for "yeah, we can almost certainly ship that". Given that this is essentially Apple's private language, I assume they'll be quite aggressive about deprecating features and moving people onto the "better" solutions (high-kinded types, richer immutability etc) when they can deliver them whilst meeting the core goals. It's an interesting approach - most other languages are happy to take a few years to get going, whereas Swift seems to want to go from 0 to 60 in 4 months. It reminds me most of C# 1.0, but with harder restrictions on what they've been told to deliver. At the moment, it's interesting, and a big leap from Objective C. By V3, it might be "excellent".

danabramov2• 12 years ago

However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0). It seems like a deliberate design choice, but one I'm not really sure about.

So did I! A few more related links if you're interested in this question:

http://schani.wordpress.com/2014/06/11/associated-types-cons...

http://www.artima.com/weblogs/viewpost.jsp?thread=270195 (this is about Scala, but Swift somewhat follows Scala with this design)

https://groups.google.com/forum/#!topic/swift-language/3Ptyd...

archgrove3• 12 years ago

Very interesting, thanks.

I also ran up against another annoying bug/oversight/v0.1ism : You can't inherit from a generic class without becoming generic yourself. So, even if you fully instantiate your parent's type information, you have to be generic as well! For example:

    class Foo<T> { ... }
    class Bar : Foo<String> { ... }

You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare:

    class Foo<T> { ... }
    class Bar<String> : Foo<String> { ... }

Which seems just odd. The best workaround I've found thus far is

    class Foo<T> { ... }
    class BarClass<String> : Foo<String> { ... }
    typealias Bar = BarClass<String>

Bleh. I've filed a radar against this one - it seems like an annoying oversight, even for this early version.

japhyr• 12 years ago

I have only a passing familiarity with Objective C. Why is one of the "red lines" having no garbage collection?

CodeWithCoffee• 12 years ago

Objective-C uses Automatic Reference Counting (Garbage Collection has been deprecated - and ARC works a lot better than the GC implementation), and as Swift had to uses Objective-C's memory model it must also use ARC.

archgrove3• 12 years ago

Apple did add garbage collection to Objective C, but it only lasted a few years before being pulled. Two less important reasons are that it's hard to integrate with the otherwise trivial C(++) interop, and the frameworks just weren't designed for it.

To me, the more important answers are deterministic destruction, and no GC pauses. All of Objective C is reference counted these days, with retain/releases inserted by the compiler (so all you have to do as a programmer is resolve cyclic references with weakness). Thus, you know exactly when an object will die, and have its dealloc method called. You're also sure you'll never end up in a situation where memory pressure causes system hitching due to GC. Given that a key platform for Objective C is iOS (low memory, "low" CPU), and that Apple's trademark tends to be fluid UI, avoiding these problems is really helpful.

drivingmenuts• 12 years ago

This makes sense - Apple's philosophy is "Everything Apple" and so they have a vested interest in designing a language that gets things moving on their platform, rather than being the best language it can be right now.

If, and this is a big if, Apple is actually interested in Swift in the long term, then they will open up the language to community development so that these sorts of things can be added by the community.

My suspicion is, though, that Swift will be improved by Apple alone and that it will be pragmatically discarded when the time is appropriate. Which doesn't mean it won't have a long life, just an undignified exit.

lxcid• 12 years ago

This is kinda misunderstanding Apple approach to introducing technology. Apple seldom introduce a technology as intermediary solution or discard them soon after. (the last time this happen that I could remember was GC in Objective-C which is replaced by ARC) They could double down on it even if it has its algorithmic flaws, and they will attempts to fix those flaws.

One of recent technologies that fall into this category is auto layout. (The performance of auto layout in iOS 7 for slightly more complex table view cells is pretty bad)

Apple main interests is always Apple, which makes sense because they are a for profit company. Just as Rails is always Basecamp. Apple technology have a fast paced development because Apple dog food their technology. WebKit in Safari, LLVM in Xcode. They invested huge in these area. That doesn't mean that they don't open up. both technologies I mentioned are open source and have huge impact to the community as a whole.

E.g. RubyMotion make use of LLVM to allows ruby to be compiled to both iOS and Android.

People like to think Apple is a closed company (as marketed by its competitors) but people who know the company well know that is far from true. They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat.

nnq• 12 years ago

must be as fast as Objective C; must have a minimal to non-existent runtime (so AOT compilation all the way); mustn't have garbage collection, must interoperate with Objective C/normal C with ease; etc.

This sounds and awful lot like what C++11/14 would bring, with a few platform specific extensions... but then again, no vendor, and especially not Apple, likes the thought of working with a language that's really trying to be cross-platform and a language that "rewards smart programmers" ( http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Key... ), as opposed to being easy-to-teach or idiot-proof...

blahber3• 12 years ago

/annoyed

I Agree with what Chris Granger said in https://twitter.com/ibdknox/status/473912605350719488.

I think Rust is a good example of developing a language in the open.

That said it's great to see Bret's ideas see more implementations.

gress2• 12 years ago

If you 'agree' with Chris Granger, perhaps you can name one of the mistakes.

Also - what good is Rust being developed in the open if it can't be used for production apps yet?

dignati• 12 years ago

Because it's not expected to be developed in the open ever and will therefore never be useful for production apps?

tkubacki2• 12 years ago

Swift seems like a nice lang, but I'm surprised that proprietary, single platform language is getting so much traction on HN.

Is it because ObjectiveC is as shitty as it seems at first sight (for C like langs dev) ?

rimantas• 12 years ago

Objective-C is far from being shitty. Your comment, on the other hand, is.

tkubacki2• 12 years ago

You are overreacting. I'm not saying it's shitty - but it SEEMS to be at least for most Java/C# devs (I know) AT FIRST SIGHT.

My hypothesis was: Objective-C is "not nice" (sorry, I'm not familiar with HN political correctness) therefore Swift feels like a true relief for iOS devs and thus this much traction.

dirtyaura2• 12 years ago

iOS is arguably one of the three top consumer software platforms (Web, Android, iOS) and a lot of people reading HN are developing for it. Personally, as a programmer, I would find Swift articles interesting and educating, even if I wasn't developing for iOS, as Swift has adopted a lot of concepts from modern statically typed languages.

oscargrouch• 12 years ago

You can expect a reasonable behaviour on HN unless it has something to do with Apple..

stephen_g• 12 years ago

I would be surprised if Apple did not BSD license the source code for Swift by the end of the year, given that they have been almost single-handedly sponsoring the framework (and employing the main developers) it's built on, LLVM, for years now - keeping it open source when there's no license requirement for them to do so.

acqq11• 12 years ago

Still, I look at the Swift with a low-level colored glasses: I don't care if this or that category theory aspect is covered or not. I don't care if you can imagine some nicer syntax for something (everybody can). I really care how good and how often Swift can be used instead of C, not being slower and not using more resources.

I know, <your-favorite-language-almost-nobody-uses> is nicer. But for me, if it has GC, it's a no go. I see Swift as something where I win when I can use it instead of writing C, not as something where I lose since the most of problems I solve by writing software I can't solve by writing in <some other language>.

Swift is impressive language for v0.1, very pragmatic in aspects I care about. So you see that there's chance it will probably be even more expressive in some other version. Nice. Even as it is, it's much nicer than any other options for the purposes for which it was designed.

_random_3• 12 years ago

The language is not "innovative" as they claim, so people are expecting at least some learning from mistakes of prior languages. They could've hired some smart people from more software-oriented companies or something.

acqq11• 12 years ago

Given the constraints, it's certainly very innovative.

coldtea3• 12 years ago

The language is not "innovative" as they claim

Not innovative compared to what? Haskell? Unfinished betas like Rust? Some language 100 people use (plus 1-2 banks and a couple of universities)?

This is a language that will jump in the top ten of most used languages in a year or so, just because it's used in a hugely popular development platform. And it had to fulfil several things to achieve that.

They could've hired some smart people from more software-oriented companies or something

Because Chris Lattner, the guy behind the infrastructure of tens of new languages and one of the most popular C/C++ compilers, is not smart enough right? Or the team that created Swift.

And which company would that be? Go, for one, is like a 1980 language compared to Swift. And C# had 14 years to evolve, and didn't have the same functionality constrains Swift has handicapped with at all.

bobbles• 12 years ago

As a fairly inexperienced programmer, can someone please explain why everyone is so happy there is no garbage collection going on?

Shouldn't that be something we would want?

(Is it because control over this allows us to do extra things?)

ludamad• 12 years ago

Reference counting has an incremental performance burden because of predictable object freeing, while garbage collection has a periodic pause. On mobile devices you often must worry about response-times; it is a lot more easy to reason 'we need to ease up on such and such at this time', and be sure you solved the problem. Garbage collection pauses can be less straight-forward to tackle.

gress2• 12 years ago

Garbage collection causes problems with memory pressure and pauses.

ARC is very little different for the programmer, but suffers less from these problems and is easier to integrate with C language code.

No reason for GC.

aidanhs• 12 years ago

There's a helpful bit of writing about garbage collection on http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

It boils down to there being a big performance penalty on garbage collection in memory-constrained environments.

acqq11• 12 years ago

Note: My post was an answer to some of the comments appearing here and not the response to the original article, which wasn't so negative as the mentioned claims.

eridius2• 12 years ago

FWIW. map() already exists. It's a global function, rather than being a protocol method, and it uses overloading. So you can still define functions merely by defining a new overload for map() that operates on your type.

eridius2• 12 years ago

Sigh, I typed "functors", not "functions", which should make a bit more sense. Autocorrect changed that without me noticing.

gfosco• 12 years ago

Since Bolts/BFTask was mentioned, I'd like to point out that you can use the Bolts-iOS library in Swift. I added a pull request with the code examples in Swift here: https://github.com/BoltsFramework/Bolts-iOS/pull/37/files

pohl5• 12 years ago

After reading this, I tried to find out which versions of Haskell and Scala introduced higher kinded types. I'm sure it wasn't among the first features. Does anybody know the history of either?

AFAIK you can't do Functor in Rust yet either, and for the same reason.

jmah2• 12 years ago

I successfully got the Functor example to work like this:

    protocol Functor {
        typealias T
        typealias FunctorResult
        func map<P>(mappingFunction: T -> P) -> FunctorResult
    }
    
    extension Dictionary : Functor {
        func map<P>(mappingFunction: ValueType -> P) -> Dictionary<KeyType, P> {
            var newDict:Dictionary<KeyType, P> = [:]
            for (key, value) in self {
                newDict[key] = mappingFunction(value)
            }
            return newDict
        }
    }

afthonos6• 12 years ago

That doesn't actually work, because you're limiting the return type of the method in the implementation of the functor. So by implementing that protocol, you could have one mapping from Int to String (say), but not another from Int to Double.

Put another way, you need to specify FunctorResult at implementation time, and the whole point is to only have to specify it at call time.

jmah2• 12 years ago

This code works:

    let d = [1: 1, 2: 2, 3: 3]
    let intToInt = d.map { $0 + 1 }
    var IntToString = d.map { String($0) }

barrkel2• 12 years ago

It's hard to implement generic functors as a protocol without either runtime code generation or generalized dynamic dispatch.

The typical efficient implementation of a protocol (aka an interface) is a vtable - an array of pointers to functions. When you instantiate a generic in a statically compiled language, that usually clones the body of the generic thing (method or type) with references to the generic parameters replaced with the type arguments; and the new, cloned body is handed off to codegen.

But if you instantiate via a protocol reference, the compiler doesn't statically know the implementation of the thing you're trying to call - it can't see the body of code to clone. It's an indirect function call through a variable, and without a restricted language, analyzing it quickly runs into the halting problem.

With runtime code generation, the problem can be solved with sufficient magic - the runtime can rewrite as necessary. That's how .NET implements this.

Alternatively, if the body of each generic method is compiled using some form of dynamic dispatch - e.g. every operation on a value whose type is a generic parameter is done via an table of function pointers, and this table is passed into the generic method at the point of every call - then it can work, at some cost in speed. Haskell works like this, AIUI.

Java does it even more simply, with full-fat dynamic dispatch - all generic parameters turn into Object, and method bodies get runtime casts inserted as necessary.

platz• 12 years ago

Some folks are working on a library for this already: https://github.com/maxpow4h/swiftz

maxpow4h• 12 years ago

yup. we have a "Functor" https://github.com/maxpow4h/swiftz/blob/master/swiftz/Unsoun... It requires constructing a "Functor" value manually, otherwise it works fine. You can still write functions over an A in Functor. The Result enum bug presented you can work around by boxing the type, such as in https://github.com/maxpow4h/swiftz/blob/master/swiftz/List.s...

The third problem a work around exists for: remove the default argument. If you want an empty init, provide one.

Sure it is buggy, but you can express these programs.

stcredzero• 12 years ago

To me, the things I tried weren’t insane; they seemed like the obvious things to try.

These are obvious things to try, from the POV of environments like Scala. That's the wrong context from which to evaluate this language. Swift is a more modern language for iOS and is most usefully evaluated in that context. (Though it is also important to also know what Swift is not in language terms.)

hit8run• 12 years ago

"She" the programmer. Seriously this sounds ridiculous and is the outcome of the shameful male "betafication" women try to establish these days. I say "he" the programmer.

Okay enugh bullshit and to the point: Swift is preview. It will get better and better fromday to day. It isn't there to mimic scala or lisp paradigms. It is there to get the job done and it will get the job done.

rsynnott5• 12 years ago

I say "he" the programmer.

Well, aren't you wonderful? Why, you'll probably win the Nobel Prize for Protecting the Poor Oppressed Men!

Alternating he and she for an abstract person is quite common amongst people who don't use singular they.

wpietri2• 12 years ago

Exactly. How will wee poor, oppressed male programmers survive as only 80 or 90% of the field?

For those wondering about the weird "betafication" thing, I recommend reading this fine blog: http://wehuntedthemammoth.com/

It's a trope of the self-anointed "men's rights" crowd, from people who are in a continual hysteria about how society is stopping them from being proper alpha males. Never quite getting that passive-aggressive anonymous-coward Internet message board comments are not how chimpanzee males work out their dominance issues.

CmonDev• 12 years ago

That's just unnecessary political correctness. It's very hip amongst a very special crowd of people. Using multiple genders somehow fixes the gender dis-balance in the craft.

ksk2• 12 years ago

Its amusing to see Apple cheerleaders defend Swift as being good enough for version 0.1 when supposedly Apple is this company that only releases products when they're complete/polished/etc. Apple themselves proclaim its "Ready Today" on their marketing page as well. (https://developer.apple.com/swift/)

rsynnott5• 12 years ago

Apple does that with _consumer_ products (well, usually; please ignore Siri). They've historically been much more willing to ship developer stuff that's very rough around the edges; the iPhone OS 2.0 SDK shipped in a barely usable state, for instance, and Xcode 4 was a similar story.

ksk2• 12 years ago

Fair enough. :)

Smashing Swift

Related Stories