Swift as a language is pretty great, however, the tooling and obj-c interop make it a pain in the ass.

It's hard to realize most of the performance benefits when everything you're interacting with requires objc_msgsend or uses NSArray / NSDictionary.

As well, it's far less 'scripty' than Obj-c. The type system in swift really leaves something to be desired in terms of typing types. The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them.

Your project probably doesn't need 1,000 developers on it who need solid interfaces and type checking to make sure that everything is going according to the UML diagram. It probably needs 2 or 3 developers who talk to each other, add asserts to their code, and a type system thats a little forgiving.

ObjC is a language that has everything you really really need, and left out the 1 thing you kinda wanted in exchange for leaving out the thousand 1 little things that everyone else wanted too. Like for example exceptions, sure they're there, but it's not idiomatic and when you program without them you realize what a crappy idea they were in practice. In day to day coding NSError is 1000x better than exceptions.

> The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them.

Can you clarify this? What is the kind of apps where a "type system would really shine"? How can you avoid writing them?

Type systems really shine in apps that you maintain. You avoid writing them by writing shovelware that intends to extract the maximum amount of money in a short term and be replaced by something else in the long term.

I don't think that's really what Obj-C was designed for.

Apps that have a lot of YAGNI features.

eg. For some reason your app has the ability to use Postgres instead of SQLite, even though you always use SQLite.

eg. For some reason your app supports Postgres/MYSQL/SQL Server because every enterprise you sell to wants to run their preferred database instead of the one that works best with your product.

In short 'enterprise' apps.

I'm not trying to be contrarian, but I fail to see what great type systems (or lack of them) have to do with YAGNI or writing poorly architected enterprise apps.

Are you saying the main application of type systems is writing overengineered enterprise apps? Do you think type systems have no place in well-architected and/or minimalist apps?

Can you elaborate more?

im saying those with a propensity to build such systems invariably choose strongly typed languages and in those languages that is the culture and the language encourages it.

Eg.rewriting base classes to use IWritableStream instead of looking up the write method and calling it.

You seem to be confusing Java-like interfaces and design patterns with types. That's not representative of what great type systems can do for you.

I'm confusing types and 'Java-like interfaces and design patterns' to the same degree that you're confusing swift's type system with 'what great type systems can do for you.'

The type system of swift is much closer to java than to that of haskell. (Or whatever language you think has a 'great' type system)

For example in F# if you just use one method the type system will infer that you need an object that has that method. (especially if that method is an operator)

eg. let add a b = a + b will work on any pair of objects that have the + operator defined. That is a good and useful type system, what swift has just makes you type more for little benefit.

eg. making types is easy, reflecting methods is hard. (it should be noted that swift effectively doesn't support reflection)

You mistake me: I wasn't talking about Swift, a language I'm barely familiar with. I was puzzled by your more general assertion about "the kind of apps where a great type system would really shine". So far you haven't explained what you meant by this; you seemed to be complaining about enterprise software, but a lot of enterprise software isn't built with programming languages featuring great or even particularly modern type systems.

I'm not sure what reflection has to do with this. I'm sure you're aware there are "great type systems" which do not use reflection.

This seems to conflate type systems with interfaces -- while not really having a clear idea what the latter serve either...

What I personally dislike about Swift is the change in mental context when dealing with the combination of C/C++ and Swift code. Plenty of nontrivial apps use significant amounts of C and/or C++ libraries in some way.

The switch when dealing with a combination of C/C++ and Objective-C source was not really a problem. But trying to interface a C++ library into a Swift application is less than a fun experience.

Personally, while the language is fresh and seems pretty good (it has some great additions), I still prefer Objective-C. I guess I'm waiting for better integration with existing libraries.

Do you have any notes on this experience posted somewhere publicly? I'd love to see an overview of the issues between Swift and C++ libraries. (Boost? Not Boost? The nuances of Swift's type system?)

You can't communicate between Swift and C++ right now... it's on their bucket list though :)

Swift's popularity has undergone a meteoric rise for a young language according to TIOBE [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....]

But that's not surprising given its ecosystem; as others have mentioned, language success has less to do about its theoretical benefits and more to do about what environments it allows the developer access to. Javascript is the case-in-point; I think few people would argue it is a well-designed language, but if you want to do web development, you're going to need at least a basic understanding of it, so it maintains brutal popularity.

The shocking thing I think isn't how fast Swift has grown, but how fast Objective-C has fallen. The stats from that site don't appear to show that Swift has made up for that.

The overall combination of Swift and Objective-C in those numbers make me believe Apple's decision to make Swift open source is less about goodwill, and more about stopping the bleeding.

Given the context it's used in, this is hardly surprising.

You'd probably get more upvotes if you didn't start out by complaining about hypothetical downvotes.

I've seen the opposite be true most of the time (and I have showdead on)

he is stating what he believes will be true. i didn't read a complaint anywhere. in fact, i think he was implying how sure he was about his folliwing statments, as he was ready to post them inspite of the (expected) downvotes.

expected things are, by their very nature, hypothetical until they come true or are proven false.

I think it's terrible. Parsing a JSON response into a Swift object takes a full-day to figure out when it's literally just JSON.parse(response) in any other language. You can't pass immutable structures (structs) into NSNotifications and I can't figure out why. It's confusing and poorly documented, and a complete chore to use.

React Native is a godsend.

>Parsing a JSON response into a Swift object takes a full-day to figure out when it's literally just JSON.parse(response) in any other language.

Something which has nothing to do with the language.

Here's how you do it with a popular Swift lib:

let json = JSON(data: response)

if let userName = json[0]["user"]["name"].string{ .... }

Eh, the awful state of their respective standard libraries seems to come up quite a bit when people are critiquing OCaml or D.

What on earth are you talking about? Parsing a JSON response in Swift is basically the same as it is in Objective C:

  let parsed: AnyObject? = NSJSONSerialization.JSONObjectWithData(data,
    options: NSJSONReadingOptions.AllowFragments,
    error:&parseError)

This is truly not meant to be a snarky comment, but why is it so overtly verbose? I left Java years ago b/c it was making my fingers arthritic it seems. It doesn't look like much fun. Sure, IDEs do autocomplete, but still requires parsing by the human eye.

I'm sure you get used to it. Every language looks horrible the first time, then you learn to live with it and maybe love it, but on first glance that looks pretty awful.

Objective-C tends to err on the side of readability. Considering that source code is read many more times than it is written it's something I personally agree with. But yeah it's something you do get used to.

Java's problem is that C# exists and is a more expressive language.

But this isn't readable at all.

If you compare it JSON.parse(x) or fromJSON x it's just awful.

The idea that more verbose == more readable is so annoying. It seems to be especially egregious in languages like Ada, which look like this to me (an uninitiated):

    okay here comes a function definition get ready
      function MyFun() begin
        return 1
      end begin
      end MyFun
    end function okay we are done

Verbosity is part of the design philosophy behind Objective-C.

How is React "native" again? I'm not sure I understand how something not written in Swift or Obj. C is 'native.' This is only 30% snark; I actually don't know the answer. React is from the same people that thought html5 was a good idea for a mobile application right? I am not bashing React; I am only curious how it's considered native. Does it have official support from the iOS APIs? Can you integrate Objective C libraries with React? I just don't get it.

I also don't get how a JSON parse takes half a day. If you know the language it shouldn't take that much time. If you don't know the language then a complaint wouldn't be intellectually honest would it?

I don't think the parent was saying React is native. He's referring to a project called React Native, which provides native rendering (eg., <Button> binds to a native button implemented in ObjC) in a PhoneGap/Cordova-style wrapper that lets you implement bridged access to native code (to talk to Apple-specific APIs or to implement performance-sensitive code, for example). In such an app, you would be able to get a native "look and feel" despite the application being written mostly in JS.

As far as i understand. It uses a javascript runtime on its own thread to parse "instructions" to native components dynamically. To answer your questions. yes, yes, yesno.

Reacts philosophy is to learn once write everywhere. If you know reactjs then it is just as easy to write react native as it is exactly the same (clear and concise) but with different api's available. The instructions are written in javascript the rendering can be done in dom, obejective-c, java.. etc.etc.

Would it be intellectually honest to place a 30% snark if you don't know the language?

They mean "React Native"[0], not React itself :)

[0] http://reactnative.com

Have you tried SwiftyJSON ?

https://github.com/SwiftyJSON/SwiftyJSON

It's better than Objective C, so I like it. But if iOS was open to every language I doubt people would be paying much attention to it.

Yeah it's only possible to write iOS apps with C, C++, C#, Ruby, Javascript, Python, LUA...

Not with first-class support is isn't.

So? Is there any platform that has first class support for more than 1-2 languages?

Unix. The 'native' language there is C but there are dozens of languages that are well-supported. They can interoperate through OS-level abstractions like pipes and via C APIs on at the process level. The average Unix desktop or server is probably running code written in 5-10 languages, more or less transparently to the user.

First, you said with first class support from the vendor. Linux doesn't offer that for any language.

Second, that's not an app development platform. Gnome has C (and it's own unholy stack on top), KDE has C++.

You can code for OS X/iOS in all kinds of languages too, if you mean at the OS and not at the app development level.

I'm afraid you have me confused with another commenter regarding the 'first-class support' issue.

If "platform" means "app development platform" and that means "full-featured toolkit for the development of GUI applications that run in an integrated environment", then I would agree both that Gnome and KDE fit that bill and that they have limited language support (in my experience the only language worth using with those toolkits other than the respective C and C++ is Python).

> They can interoperate through OS-level abstractions like pipes and via C APIs on at the process level.

And you can't do this in OSX or iOS?

> The average Unix desktop or server is probably running code written in 5-10 languages, more or less transparently to the user

The average iPhone is probably running code written in just as many (if not more) languages - C, C++, Obj-C, Swift, and Javascript are a given before you even look at third party stuff. And, modulo sandboxing, you can do all the Unix stuff too.

Sandboxing is a pretty big modulo.

I actually don't have any opinion on how many languages have 'first-class' support on iOS. My understanding is that it's somewhat more complicated to create natural-seeming bindings from other languages to Objective-C APIs than it would be for C APIs, and that there are restrictions in the type of applications you can distribute using other languages (no downloadable code outside the App Store). Whether that makes those languages not 'first-class' on the platform is up to interpretation.

But the person I was responding to was specifically asking if any platform had first-class support for more than 1-2 languages. I don't know how to determine 'first-class' as a matter of principle, but I assumed that the multiple decades of polyglot software development on Unix environments would count. (OS X would count there, by the way.)

Sandboxing affects obj-c and swift code too.

I enjoyed it well enough. Didn't feel quite mature (refactoring tools, error handling, etc) and optionals are still a little frustrating, but it definitely feels like it has potential.

I love it. It's a gateway drug to functional programming, and "doing" functional programming, in turn, helps me write more expressive Swift code. It's still rough around the edges, but it's a beautiful language that's a joy to use.

> I haven't really enjoyed swift so far

I haven't either, but I haven't used it a lot so I can't give a final verdict on it. But I'm the kind of person that enjoys C++ (well, especially after C++11, feels like a new language and I'm slowly becoming a C++ fanboy), and I guess all those new system languages like Swift and Rust are supposed to fill the void for people that don't like the existing system languages available, so maybe it's not for me.

I find it far less frustrating to use than Java, as it actually has decent generics.