Swift WTF

I thought that was curious, so I put one of their code samples to the test:

Swift WTF: http://swiftwtf.tumblr.com/image/88465530183)

But it looks fine on my machine (Xcode 6.2): http://imgur.com/rJU7lcx

Yeah, this is silly to talk about now. I'm sure you can dig up plenty of WTF things about the latest Swift, but few if any of these examples are still valid.

This is a blog whose latest entries deal with Xcode 6.0 beta 3 (out of at least 7 eventual betas, many of which made substantial changes to the language). Right now, the 'standard' Swift version is Xcode 6.1's (Swift 1.1), and Swift 1.2 is in its third beta. So it's definitely not representative of the current state of the language (which was, admittedly, in pretty awful shape at that point in time).

It kinda seems like it already has run out of content. Most of the examples are using either a beta version of Xcode or version 6.0, at least 2 minor versions behind. As a few people have pointed out, some of the examples aren't even reproducible on the current versions.

>Swift is still very new, crashes in the language and in the IDE will not surprise anyone who calls himself a software engineer.

And yet Rust is reliable as fuck even in its current shape.

Swift has no excuse to be so unpredictable, especially given that it's back by a humongous commercial company.

I've never done any iOS development due to job market (mostly contracts/consulting, not my kind of thing at the moment) and due to Apple track record on Development Environment (Drag-n-Drop, meh-IDE, etc) but I have to wonder, Microsoft, GWT (when it was still backed by Google), Android UI, Qt do support (or move toward the direction of) declarative UI model type of development. Only Apple that does not (right now I guess), what gives?

Most platforms that come out these days usually have support for:

1) dependency management

2) some sort of way to make build from command line (CI integration)

3) unit-testing framework and runner

4) SCM strategy that unifies unit-test/integration-test runner, build the thing, package it to the point of ready to ship...

How are these handle in the world of iOS which is backed by a multi-billion dollars company?

> The biggest pain is apple's frameworks and ide. The APIs are very inelegant and arbitrary.

I can't agree with that at all – Apple's frameworks are among the most consistent I've ever seen. They have a small number of solid design patterns that they stick to that serve them very well. Picking up new frameworks is usually extremely easy because of this consistency. They are far beyond JavaScript in this respect.

> The worst thing is the drag and drop interface builder. I believe that the people who designed it never actually built an iPhone app with it. You can always get about 80% of what you want, then you have to resort to some outrageous hack and stitch the rest of it together with verbose imperative code.

Interface Builder certainly has its shortcomings, but the most frequent complaints I see about it are from people who haven't taken the time to learn it properly and fall back to imperative code in preference to learning how to use Interface Builder properly.

Also, 80% declarative UI and 20% imperative code is a pretty fair mix – unless you are designing extremely simple applications, you shouldn't expect to put together an entire user interface using nothing but drag and drop tools. That's not an effective way to work regardless of the quality of the drag and drop tools.

> Declarative web dev with html really is a huge step up from Apple's stupid drag and drop thing.

They are really two different worlds. Most of the time, one or the other is clearly the better choice for any given project, but it doesn't really make sense to say that one is better than the other overall.

Swift's rules are pretty simple too: true is true, false is false, and nothing else is any sort of boolean. If you want to check whether an array is empty, do so explicitly. If you want to test an integer for zero, you have to do == 0. Even testing for nil requires an explicit != nil.

As for equality, I think it's just old bugs from an old prerelease compiler. These posts are ancient history, relatively speaking. I just tested on the latest public release and a == [1], [1] == a, and [1] == [1] all produced true, as one would expect. str === str won't compile, also as one would expect (String is a value type, and as such comparing object identity is nonsensical).

PHP is pretty bad, but I think JS really takes the crown for insane equality comparisons. Basically every weird equality comparison from PHP is in JS, along with some other humdingers like 0 == [].

And my favorite, '\n\r\t' == 0

> So far I understood Swift to be the next big thing in terms of hot programming languages with a functional flavor.

Swift is tightly coupled to Apple's platforms (which are of course commercially very viable, and if you develop for them you should be looking at Swift), under a proprietary license and developed under closed governance. It's a legitimate product, but under those circumstances it doesn't really have a shot at being a NBT in programming by itself, beyond contributing its ideas to wider discourse.

It's obvious that no generally relevant library/infrastructure will be written in Swift, for example; if anyone with a great idea choses to implement it in Swift first for whatever reason, it will be a reimplementation in another, more widely useful language that gains widespread popularity.

Swift may in fact be the exception to that rule, as everyone complains about it and almost no-one uses it ;)

That is a terrible quote, provided by an author trying to defend a fairly awful language. It is rhetorically weaselly, attempting to cast aspersions at critics, without actually providing meaningful defenses.

you classify a problem you don't even fully understand as easily solved because you're willing to spend other people's money freely. you have upper management written all over you.