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.
Can you clarify this? What is the kind of apps where a "type system would really shine"? How can you avoid writing them?
I don't think that's really what Obj-C was designed for.
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.
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?
Eg.rewriting base classes to use IWritableStream instead of looking up the write method and calling it.
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)
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.
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.
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 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.
expected things are, by their very nature, hypothetical until they come true or are proven false.
React Native is a godsend.
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{ .... }
let parsed: AnyObject? = NSJSONSerialization.JSONObjectWithData(data,
options: NSJSONReadingOptions.AllowFragments,
error:&parseError)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.
Java's problem is that C# exists and is a more expressive language.
If you compare it JSON.parse(x) or fromJSON x it's just awful.
okay here comes a function definition get ready
function MyFun() begin
return 1
end begin
end MyFun
end function okay we are doneI 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?
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?
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.
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).
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.
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.)
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.