Most non-coders have the same attention spam as a Linux distro.

Soon enough, their free time forks off into another party. And we're not invited.

They are called Jobs Crisis and are meant as guidance. Solutions are the realm of the secret, hidden Second Jobs.

Cities are going to be built around this.

Because already they had too much.

Actually, it was the other way around.

I started with a blank project to write a Swift framework in order to learn the language and reach a usability goal of signing into a production server, make a couple of REST calls and yield out Switch class instances in a hierarchy, through unit tests. No UI.

Then I proceeded to replicate the same thing in Obj-c using the same class hierarchy, same object model. There was a near 1:1 correspondance in the whole thing. Where things differed were where Switft could not directly handle things like NSClassFromName where an Obj-C factory was embedded in the Swift code.

The exact numbers (now that you got me out of bed) was 84,341 bytes (file system rounded to 184k) for 29 items for the Obj-C version and 249,282 bytes (324k) for 23 items for Swift.

Size comparaison is no longer possible because the Swift was frozen on ice since jully-ish while the Obj-C version given considerable more smarts, expanded object model, additional services (REST calls handlers) and additional auth method (Basic, SSO, Form with redirection support while Swift only had Basic auth).

And yes, I know Swift is a moving target (we all cringed when they promised not to promise source compatibility between releases...). I can only hope it keeps on getting better. I just dont think its mature enough for a corporate environment such as ours.

Wish I could show side-to-side comparaison of where the major differences where and why swift ended up taking more code but sharing code is not the kind of thing my employer is very keen about (they own java and we all know how that went).

I can tell you where is a lot of "as String" or "as NSString" going on, and things like foo!.dynamicType(). One line I'll replicate is this one:

                                        var version : NSString = bundle?.infoDictionary["CFBundleShortVersionString"] as NSString

Isn't it completely useless and mind boggling that I have to use "as NSString" at the end of this line if I took the express care of typing the "version" variable as NSString? Damnit, the compiler should be smart enough to do it for me. Things like that really need refinements. This ain't Hypertalk (remember that?).

Noteworthy is that I used the same coding style in both language in terms of line spacing, variables/types alignments using tabs and K&R style braces. As long as style did not contravene the convention of the language.

And I thought I was pretty nice (in Swift's favour) to not have mentioned "SourceKit crashes". But that's an XCode issue, not a language one.

The code was written for production consideration. In the end, the Obj-C version was retained. Yup. NSJsonSerializer. The was a level of abstraction around it to allow using a different (and faster) engine but not during those tests.

The wrapper includes facilities to map the resulting NSDicts to corresponding classes if they existed, or use custom class maps for customizing recipient objects based on calls. This conversion of dictionaries to class instance is recursive. Meaningful keys are also trapped on a per class basis so a -toJson round trip can be achieve, including optional retaining of unknown values (should the server object model not match the compiled classes. That was the part that Swift had shortcomings.

About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic. For an inferred type language, you sure have to write an effin lot of garbage.

Wether your code is small and modular doesn't change the fact that you are still sending out entire source code out rather than simple headers that outline intended usage. When dev group x sends code your way, if the interface is full of symbols you should not directly access, wether they are marked privates still doesn't make the published code easier to deal with.

The Obj-C mangled names was in the documentation and WWDC presentation at Time of This comparative exercise.

And yes, code size was bigger in swift. Despite having 2/3 the number of files that the Obj-C version had (due to the header+mplementation duets). The exact numbers on my laptop but off the top of my head it was 234kb for Swift and 182 for Obj-c. If I could upload pics in /. Comments, I have a screenshot of both folders inspectors opened.

You can work out the syntax in under a week. It's an academic exercise at worst.

The real problem lies in the language itself.

The playground is a cool nifty feature but it's not something that could not be done with clang/obj-c. There was a time we could fix-and-continue code at runtime. They removed the feature instead of fixing it (at a time it was based on GCC).

Even today, using framework for custom views in Obj-C, you can code changes in your view code and see live changes in your layout files (xibs/storyboards) as you work in the code (I love this new features).

Speaking of IB_DESIGNABLEs, while they are awesome for special view coding for drawing custom content, they still lack the ability of interacting with their subviews in IB (the code is being called to render the view, without it's content), making its use for layout views not possible (such as a content-sorting or layout view).

Definitely Objective-C, unless your intent are for small home projects no one else will ever have to deal with.

Here is a bunch of random notes I took when evaluating Swift...

- No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.

Q: Is there any private/public scoping in the language?
A: None! It's wide open. Apple promised at the WWDC to fix that. But it will probably take the form of private/protected keywords much like C++ in the class definition. They seem hard-bent on not having public header files.

- Access Control

In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:
private entities are available only from within the source file where they are defined.

Internal entities are available to the entire module that includes the definition (e.g. an app or framework target).
public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.

Ie: public class ListItem { // Public properties. public var text: String public var isComplete: Bool
}

Problem with that is regardless of access control, you are still exposing your entire class code and layout to users of it, preventing any restriction on class access for "consumable non-internal" implementations.

- optional means object can be nil. But they're just a wrapper.

Real-world test code being written showed you end up peppering your code with ? and ! symbols.
Using ! unwraps a var to it's value. CHECK FOR NIL or use if let

Ig target.foo?() unwraps to if [target respondsToSelector(foo)] target.foo()

-weak reference need to be optional

-Swift "module" import uses the project group name; change a file from group and suddenly is out of the module

-AnyObject = id or Class type

Can't upcast AnyObject to a static type
  wrong: var view: NSView = anyObject
  need to upcast using as
      var view: NSView = anyObject as NSView
  or tested
      var view: NSView = anyObject as? NSView

- Arrays upcast arrays: for item in myItems as NSButton[]

Your code end up having full of "as othertype" in it. So much for inferred type.

Random bridging nastiness:

-NSError** gets magically translated as NSErrorPointer
  and you still need to pass by reference: &error
  and then receiver must unroll pointer using !

- useless notations like optionals:

  foo?.prop?.prop?.prop.ToInt()
vs foo.prop.prop.prop.intValue;

  Saved nothing. Obj-C can already handling nil object dereferencing

- Integration with existing code: Obj-C require Swift mangled name

  SWIFT_CLASS("_TC5MyApp10MyDocument")

-STL-style templates

@objc func myGeneric(x:T)-> (String,String) {} ensures
  func can be expressed in Obj-C at compile type

Need I say more?

- Specify obj-c accessor:

  var enabled : bool
  {
    @objc(isEnabled) get {...}
  }

  further obfuscate the .swift file (remember: NO HEADERS!)

- Swift does not fix the CF bridging issue

Unmanaged for manual memory management. ie

  let color = CGColorGetRandomColor().takeUnretainedValue()

  Force the memory convention by annotating the header

  CF_IMPLICIT_BRIDGING_ENABLED() //header content
  CF_IMPLICIT_BRIDGING_DISABLED()

- String-types enums are a major fubar

Given

enum Method : String
{
case GET = "GET"
case POST = "POST"
case DELETE = "DELETE"
case PUT = "PUT"
case PATCH = "PATCH"
}

class Foo
{
var method : Method
}

func doSomething()
{
  var foo = Foo()
  var methodType : String = foo.method
}

will ultimately fail with cryptic and wrong error messages like "could not find member" on method

Proper syntax is

let urlMethod = request?.method.toRaw()//sheesh...

-typedef in Swift is typealias

-As of XC6b5:

New "dynamic" keyword ensures KVC exposure for swift class data members:

class ...
{
dynamic var x: Int ...

-There are inherent security risks using swift strings where format string, rather than take placeholders like %@ or %1@ actually embed the variable names, such as var credentials = "\(auth.username)".

The localized strings would thus expose the structure layout making it easier to hack into the binary at runtime, including potential code injection hook points.

-Aint that interesting. The exact same Swift FooSW framework re-created in Objective-C as FooOC, takes HALF as little code for an exact class-for-class version retaining all the same code patterns.

-swift can not format some strings such as hexadecimal strings of specific float format like %.2f or %X directly. One must use NSString.

-new in XCode 6b5: Optionals can now be compared to nil with == and !=

-XC6b5: A new ?? nil coalescing operator has been introduced. ?? is a short-circuiting operator, similar
to && and ||, which takes an optional on the left and a lazily-evaluated non-optional expression on the right. (15247356)

-Danger Will Robinson!

using operator += with arrays CONCATENATES ARRAYS rather than add right array as an element of left array:

var left = [1,2,3]
var right = [4,5,6]

left += right

produces

left == [1,2,3,4,5,6]

rather than

[1,2,3,[4,5,6]]

which may be an issue when building an array of unrelated items (like, building a matrix of sort).

Lastly, I want to stress that for the purpose of evaluating swift in a production environment, I created a REST/JSON multi-threaded transaction framework with full JSON object parsing through an object factory that returned fully instantiated objects (this required Obj-C support for Swift since it could not do KVC just yet: something that was promised and am not 100% if it made it in yet: look it up). Additional functionality was transaction response (using the a common java target.dosomething().then().then().fail() code pattern), cancellable transaction and statistics gathering on mean-time-to-transaction-completion on a per REST command basis (ie, the REST URL before parameters).

The end result in swift was twice as much code as the Obj-C counterpart which implemented as much functionality (and didn't require a second language to fill the gaps). Obj-C was also marginally faster when unrolling JSON but that may be due to the fact is did not require a second language to deal with introspection (KVC).

The biggest issue I found in swift was all the awkwardness and false claims. Biggest one was where the language was slated as being "All of Objective-C without the C baggage" which turns out to be full of croc.

Stupid things like "we fixed switch statements by removing the repetitive break keyword" and then introducing the exact opposite "fallthrough" keyword, did essentially NOT fix switch statement: it just made it error-prone for that junior/intern programmer that's coming in to screw up your code.

That test framework was built with a multi-programmer, globally-spread coding team such as what I have to deal with at the office. Exposing intended consumable APIs while concealing internal implementation details is basically not possible under Swift, unless you start separating your project in Binary-back-end + Swift-Consumable-Front-End which is an organizational nightmare compared to simple Obj-C headers and private categories in .m files.

Discuss.

They actually cached in lots of their stock one month before the release of the iPhone.

They knew very well what was going on.

Ferguson.

I'm still in the 2nd edition of TSR though.

It'll kill people by the millions. Spontaneously conjuring plagues and first-born viruses.

Whoosh.
Either way, the pun is over the biblical unilateral pro-god nature of the OS.
No de[a]mons there.

Or any kind of demons.