I've been learning Swift over the last couple of weeks. As a full-time C and Python developer it really just feels like a combination of those two (stronger typing and compiling like C with a lot of the array, dictionary, looping of Python). I'm using it to create an OSX/iOS/AppleWatch (yes - targeting all three) app.
I never did like Objective-C... all the damn square-brackets are just plain garish and a lot of the extra symbol "sprinklings" (like @ signs everywhere) was too much like Perl... adding characters and reducing readability.
The only weirdness so far with Swift is the Optional. I understand what they were going for... and it is nice to have that built right into the language... but it brings us back to C land where essentially everything is passed around like a pointer (an Optional) and that pointer can be NULL... and you have to dereference that pointer all the time to actually get at your data. It's "good" in a way... but also cumbersome. Maybe I'll get used to it over time.
So far I think Swift is a step in the right direction. It's definitely going to bring new devs to the platform since syntactically it acts like most other modern programming languages...
If porting your app to Android is double the work, why do it? Why not spend that effort writing another app for iOS since the App Store is so much more lucrative anyway?
Apparently you don't have any clue about the business of apps.
90% of the paid apps are loss making for the developer (but not for Apple), and a shiny 1% of the apps make big profits. In order to make a profitable business one needs a great idea, excellent execution and huge marketing. So it is 1000 times easier to expand an idea to another platform, than to come up with a new lucrative idea. For the 2 apps that I have developed and published myself, 65% of the income comes from Android and 35% from iOS. So why should I throw away this 65% and start a risky new app with no guarantee of any income?
I also make apps for 3rd parties, and it is my major source of income for the moment. I am currently making one for the European Commission. I have to make the app for both platforms simultaneously, or I could not have won the contract.
So yes it is a very legitimate requirement to have a single mobile web development environment, and it is too bad Swift won't help
Huh? Are we talking about he same thing? A union type is a common supertype to two otherwise unrelated types. For example, a String | Integer. Having this feature at the language level allows for some very powerful features.
We are, but if you think of it a union is a struct with special storage requirements (only one member is stored at the same time), and this can be seen as a storage optimization feature, not a language (logical) feature. In short you don't need unions on the conceptual level.
If porting your app to Android is double the work, why do it? Why not spend that effort writing another app for iOS since the App Store is so much more lucrative anyway?
Apparently you don't have any clue about the business of apps.
90% of the paid apps are loss making for the developer (but not for Apple), and a shiny 1% of the apps make big profits. In order to make a profitable business one needs a great idea, excellent execution and huge marketing. So it is 1000 times easier to expand an idea to another platform, than to come up with a new lucrative idea. For the 2 apps that I have developed and published myself, 65% of the income comes from Android and 35% from iOS. So why should I throw away this 65% and start a risky new app with no guarantee of any income?
I also make apps for 3rd parties, and it is my major source of income for the moment. I am currently making one for the European Commission. I have to make the app for both platforms simultaneously, or I could not have won the contract.
So yes it is a very legitimate requirement to have a single mobile web development environment, and it is too bad Swift won't help
So, how do you currently develop cross-platform apps?
I get tired of reading such criticisms and put-downs of Daniel's writings. If you don't like what he writes, don't read it.
My take is folks like you call articles such as this one "puff pieces" because they stand in contrast to the mostly idiotic criticisms and hit pieces published by people at CNET and the like.
I say if you want to offer Daniel constructive criticism, contact him privately, instead of throwing things out for everyone to see.
I don't usually comment, but as an app developer I thought I might be able to add something to this discussion.
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c. 2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes. 3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
So, how do you currently develop cross-platform apps?
For the parts that are not performance sensitive I am using the Cordova tool chain which it using Webviews (HTML + javascript), the other parts are written in ObjectiveC on iOS and Java on Android. Although the ObjectiveC and Java parts are maximum 10 % of the functionality, they represent 50% of the code and 80% of my development and debugging time. Once an app is installed almost all reported bugs are in the ObjectiveC and Java parts.
So, how do you currently develop cross-platform apps?
For the parts that are not performance sensitive I am using the Cordova tool chain which it using Webviews (HTML + javascript), the other parts are written in ObjectiveC on iOS and Java on Android. Although the ObjectiveC and Java parts are maximum 10 % of the functionality, they represent 50% of the code and 80% of my development and debugging time. Once an app is installed almost all reported bugs are in the ObjectiveC and Java parts.
I am not a professional programmer -- but have some web development experience (JavaScript, Perl, PHP, ColdFusion) and have some Java, Obj-C and now Swift programming under my belt.
From my perspective, it seems you might be better off using Swift and Java as opposed to Obj-C and Java. It won't give you a cross-platform code base, but it could make you more productive. because:
Swift Syntax is more like Java Syntax than Obj-C syntax
Swift Syntax is more concise (less cruft) and less fiddly than Obj-C
Swft code is faster to write and debug than Obj-C
Swft code is more readable & maintainable than Obj-C
If the Swift code compiles, It will run with fewer crashes than Obj-C
You can leverage existing Obj-C Code by adding Swift Code in the same project (Mix and Match)
Swift runtime outperforms Obj-C runtime (and likely C runtime, before long)
It saddens me that you [are forced to] use HTML & JavaScript to realize 90% of your cross-platform needs ... I suspect that it is used, mostly for UI -- and leads you to address the LCD of features of Android and iOS.
My long-term assessment is that Swift is bigger than Apple -- and, within several years, will go the way of Darwin and WebKit.
I don't usually comment, but as an app developer I thought I might be able to add something to this discussion.
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes.
3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
I'll give you a +1 for just about everything you said there. I also think the Swift syntax is terrible, hard to read and I have exactly the same issue trying to understand code written in it from a couple of weeks back, which is never an issue with ObjC. It doesn't help that the language is currently full of inconsistencies, choices not thought through to their logical conclusion and missing features which ends up with you having to write code which works around the language, not with it and that leads to contorted hard-to-understand code.
Swift is fine if all you want to do is drive the Cocoa framework simply from a scripting language, and a lot of people write objective C that way too. If however you really try to use the supposed power of generics and protocols and associated types you very quickly find huge holes in the entire design which it will take a lot of thinking about on the part of the Swift team to sort out and which, had Apple written something real and large in Swift before releasing it, they'd have quickly found. If you read the developer forums you quickly see the only way to work around some of the language limitations is to write some very unintelligible code.
The terrible buggy state of the compiler and tools hasn't helped at all, but that's not really the biggest issue with Swift as an advanced language at this point, it's currently just not very good.
I returned to objective C after a month trying to get a new project written in Swift, I'm back to being productive. I look forward to seeing all these shortcomings addressed in Swift 2.0 which I expect not before WWDC this year. Swift will get there but I'm surprised constantly by the people who think it's great at this point, that's far from my experience.
We are, but if you think of it a union is a struct with special storage requirements (only one member is stored at the same time), and this can be seen as a storage optimization feature, not a language (logical) feature. In short you don't need unions on the conceptual level.
I don't usually comment, but as an app developer I thought I might be able to add something to this discussion.
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes. 3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
There are several Obj-C/C++ wrapper examples ... Does this help the situation?
Also, as to Marketing Fluff -- I don't consider Chris Lattner a marketeer -- Not only did he create Swift, but he was responsible for Apple's implementation of LLVM ... He has come credentials.
I don't usually comment, but as an app developer I thought I might be able to add something to this discussion.
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes.
3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
I'll give you a +1 for just about everything you said there. I also think the Swift syntax is terrible, hard to read and I have exactly the same issue trying to understand code written in it from a couple of weeks back, which is never an issue with ObjC. It doesn't help that the language is currently full of inconsistencies, choices not thought through to their logical conclusion and missing features which ends up with you having to write code which works around the language, not with it and that leads to contorted hard-to-understand code.
Swift is fine if all you want to do is drive the Cocoa framework simply from a scripting language, and a lot of people write objective C that way too. If however you really try to use the supposed power of generics and protocols and associated types you very quickly find huge holes in the entire design which it will take a lot of thinking about on the part of the Swift team to sort out and which, had Apple written something real and large in Swift before releasing it, they'd have quickly found. If you read the developer forums you quickly see the only way to work around some of the language limitations is to write some very unintelligible code.
The terrible buggy state of the compiler and tools hasn't helped at all, but that's not really the biggest issue with Swift as an advanced language at this point, it's currently just not very good.
I returned to objective C after a month trying to get a new project written in Swift, I'm back to being productive. I look forward to seeing all these shortcomings addressed in Swift 2.0 which I expect not before WWDC this year. Swift will get there but I'm surprised constantly by the people who think it's great at this point, that's far from my experience.
I've heard similar opinions/experiences to yours.
Just out of curiosity:
What version of Xcode were you using when programming with Swift?
Thanks for the link but that info isn't new to me.
Functional languages (can) use this in an elegant way, but this really isn't anything different from subclasing and switching on the (sub) type, no biggie.
... If however you really try to use the supposed power of generics and protocols and associated types you very quickly find huge holes in the entire design which it will take a lot of thinking about on the part of the Swift team to sort out and which, had Apple written something real and large in Swift before releasing it, they'd have quickly found. If you read the developer forums you quickly see the only way to work around some of the language limitations is to write some very unintelligible code.
...
I would be very much surprised if this was the case.
Maybe you could provide some clear examples of the 'huge holes in the entire design'?
Thanks for the link but that info isn't new to me.
Functional languages (can) use this in an elegant way, but this really isn't anything different from subclasing and switching on the (sub) type, no biggie.
I guess we should agree to disagree, because I see a monumental difference between syntactic sugar around a struct with conditional members and a fundamental feature of many language's type systems, including Haskell, ML, OCaML, Ceylon, etc.
If I want a union between String and Integer, how do I do this in your subclassing example? I would need to treat both as Object? In my switch statement, I would need to explicitly check for String or Integer and then throw an Exception in the default case. This is type unsafe, and furthermore my function signature of the function that takes Object is unclear. The function definition does not clearly express the intended types of the function, leading to confusion and a high possibility of runtime errors. It's sort of a contrived example, but I've seen real-life use cases of functions that take Strings or Integers being overloaded and more or less having the same logic in each method.
I see a number of useful use cases:
1) The best implementation of Optional I can think of. For an instance, an Optional implement as String|Null (union of String and the Null type). 2) Expressing a function that could return one of two types. A good example is a String or some sort of Error type on a function that does some sort of computation. If the computation succeeds, return a String, otherwise, an Error. 3) (Similar to the point I made above) Facilitating an alternative to overloading. If you have a function that can take as one of its parameters either a String or an Integer, instead of having two separate functions with different logic, write one function with a union type with conditional logic on the union type inside the function. 4) Enumerated types or algebraic types. By intentionally limiting the subtypes of a type hierarchy, it's possible to, for instance, limit the case statements within a switch and not have to assert the default case isn't selected, for example. 5) Collections and other generic containers can be more flexible by explicitly denoting and limiting the possible types with a union. I can invoke the function in example 2) and get back a series of unions of String or Error, making this transparent to the type system and the reader of the code. 6) Eliminating a whole bunch of boilerplate in typical Java-style class hierarchies.
I guess we should agree to disagree, because I see a monumental difference between syntactic sugar around a struct with conditional members and a fundamental feature of many language's type systems, including Haskell, ML, OCaML, Ceylon, etc.
If I want a union between String and Integer, how do I do this in your subclassing example? I would need to treat both as Object? In my switch statement, I would need to explicitly check for String or Integer and then throw an Exception in the default case. This is type unsafe, and furthermore my function signature of the function that takes Object is unclear. The function definition does not clearly express the intended types of the function, leading to confusion and a high possibility of runtime errors. It's sort of a contrived example, but I've seen real-life use cases of functions that take Strings or Integers being overloaded and more or less having the same logic in each method.
I see a number of useful use cases:
1) The best implementation of Optional I can think of. For an instance, an Optional<String> implement as String|Null (union of String and the Null type).
2) Expressing a function that could return one of two types. A good example is a String or some sort of Error type on a function that does some sort of computation. If the computation succeeds, return a String, otherwise, an Error.
3) (Similar to the point I made above) Facilitating an alternative to overloading. If you have a function that can take as one of its parameters either a String or an Integer, instead of having two separate functions with different logic, write one function with a union type with conditional logic on the union type inside the function.
4) Enumerated types or algebraic types. By intentionally limiting the subtypes of a type hierarchy, it's possible to, for instance, limit the case statements within a switch and not have to assert the default case isn't selected, for example.
5) Collections and other generic containers can be more flexible by explicitly denoting and limiting the possible types with a union. I can invoke the function in example 2) and get back a series of unions of String or Error, making this transparent to the type system and the reader of the code.
6) Eliminating a whole bunch of boilerplate in typical Java-style class hierarchies.
Your comments about type safety and convenience are valid. So your right it has additional value to have optionals in a language.
But to answer your question: create a class StringIntegerUnion and subclasses StringFromStringIntergerUnion and IntegerFromStringIntegerUnion.
That will make it completely type safe and absolutely clear to read and will give no runtime errors.
In general I think it's not a good idea to think in terms of unions made of basic types, most code should not need that.
I fail to see the difference (did you take 'associated values' in account)?
Can you give an example what you can't do with Swift enums (with associated values) that you can do with optionals?
Comments
I never did like Objective-C... all the damn square-brackets are just plain garish and a lot of the extra symbol "sprinklings" (like @ signs everywhere) was too much like Perl... adding characters and reducing readability.
The only weirdness so far with Swift is the Optional. I understand what they were going for... and it is nice to have that built right into the language... but it brings us back to C land where essentially everything is passed around like a pointer (an Optional) and that pointer can be NULL... and you have to dereference that pointer all the time to actually get at your data. It's "good" in a way... but also cumbersome. Maybe I'll get used to it over time.
So far I think Swift is a step in the right direction. It's definitely going to bring new devs to the platform since syntactically it acts like most other modern programming languages...
If porting your app to Android is double the work, why do it? Why not spend that effort writing another app for iOS since the App Store is so much more lucrative anyway?
Apparently you don't have any clue about the business of apps.
90% of the paid apps are loss making for the developer (but not for Apple), and a shiny 1% of the apps make big profits. In order to make a profitable business one needs a great idea, excellent execution and huge marketing. So it is 1000 times easier to expand an idea to another platform, than to come up with a new lucrative idea. For the 2 apps that I have developed and published myself, 65% of the income comes from Android and 35% from iOS. So why should I throw away this 65% and start a risky new app with no guarantee of any income?
I also make apps for 3rd parties, and it is my major source of income for the moment. I am currently making one for the European Commission. I have to make the app for both platforms simultaneously, or I could not have won the contract.
So yes it is a very legitimate requirement to have a single mobile web development environment, and it is too bad Swift won't help
We are, but if you think of it a union is a struct with special storage requirements (only one member is stored at the same time), and this can be seen as a storage optimization feature, not a language (logical) feature. In short you don't need unions on the conceptual level.
So, how do you currently develop cross-platform apps?
Well put!
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes.
3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
So, how do you currently develop cross-platform apps?
For the parts that are not performance sensitive I am using the Cordova tool chain which it using Webviews (HTML + javascript), the other parts are written in ObjectiveC on iOS and Java on Android. Although the ObjectiveC and Java parts are maximum 10 % of the functionality, they represent 50% of the code and 80% of my development and debugging time. Once an app is installed almost all reported bugs are in the ObjectiveC and Java parts.
I am not a professional programmer -- but have some web development experience (JavaScript, Perl, PHP, ColdFusion) and have some Java, Obj-C and now Swift programming under my belt.
From my perspective, it seems you might be better off using Swift and Java as opposed to Obj-C and Java. It won't give you a cross-platform code base, but it could make you more productive. because:
It saddens me that you [are forced to] use HTML & JavaScript to realize 90% of your cross-platform needs ... I suspect that it is used, mostly for UI -- and leads you to address the LCD of features of Android and iOS.
My long-term assessment is that Swift is bigger than Apple -- and, within several years, will go the way of Darwin and WebKit.
I don't usually comment, but as an app developer I thought I might be able to add something to this discussion.
Firstly I generally like DED's articles, you have to take them with a pinch of salt, but I thoroughly appreciate the effort he puts into them.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes.
3. If I can't easilly mix it will C++, I simply won't have a use for it.
I also want to add, that everything Apple has publicly said about swift is just marketing fluff.
I'll give you a +1 for just about everything you said there. I also think the Swift syntax is terrible, hard to read and I have exactly the same issue trying to understand code written in it from a couple of weeks back, which is never an issue with ObjC. It doesn't help that the language is currently full of inconsistencies, choices not thought through to their logical conclusion and missing features which ends up with you having to write code which works around the language, not with it and that leads to contorted hard-to-understand code.
Swift is fine if all you want to do is drive the Cocoa framework simply from a scripting language, and a lot of people write objective C that way too. If however you really try to use the supposed power of generics and protocols and associated types you very quickly find huge holes in the entire design which it will take a lot of thinking about on the part of the Swift team to sort out and which, had Apple written something real and large in Swift before releasing it, they'd have quickly found. If you read the developer forums you quickly see the only way to work around some of the language limitations is to write some very unintelligible code.
The terrible buggy state of the compiler and tools hasn't helped at all, but that's not really the biggest issue with Swift as an advanced language at this point, it's currently just not very good.
I returned to objective C after a month trying to get a new project written in Swift, I'm back to being productive. I look forward to seeing all these shortcomings addressed in Swift 2.0 which I expect not before WWDC this year. Swift will get there but I'm surprised constantly by the people who think it's great at this point, that's far from my experience.
Read this
http://en.m.wikipedia.org/wiki/Tagged_union
See:
http://stackoverflow.com/questions/24042774/can-i-mix-swift-with-c-like-the-objective-c-mm-files
There are several Obj-C/C++ wrapper examples ... Does this help the situation?
Also, as to Marketing Fluff -- I don't consider Chris Lattner a marketeer -- Not only did he create Swift, but he was responsible for Apple's implementation of LLVM ... He has come credentials.
I've heard similar opinions/experiences to yours.
Just out of curiosity:
Thanks for the link but that info isn't new to me.
Functional languages (can) use this in an elegant way, but this really isn't anything different from subclasing and switching on the (sub) type, no biggie.
I would be very much surprised if this was the case.
Maybe you could provide some clear examples of the 'huge holes in the entire design'?
Thanks for the link but that info isn't new to me.
Functional languages (can) use this in an elegant way, but this really isn't anything different from subclasing and switching on the (sub) type, no biggie.
I guess we should agree to disagree, because I see a monumental difference between syntactic sugar around a struct with conditional members and a fundamental feature of many language's type systems, including Haskell, ML, OCaML, Ceylon, etc.If I want a union between String and Integer, how do I do this in your subclassing example? I would need to treat both as Object? In my switch statement, I would need to explicitly check for String or Integer and then throw an Exception in the default case. This is type unsafe, and furthermore my function signature of the function that takes Object is unclear. The function definition does not clearly express the intended types of the function, leading to confusion and a high possibility of runtime errors. It's sort of a contrived example, but I've seen real-life use cases of functions that take Strings or Integers being overloaded and more or less having the same logic in each method.
I see a number of useful use cases:
1) The best implementation of Optional I can think of. For an instance, an Optional implement as String|Null (union of String and the Null type).
2) Expressing a function that could return one of two types. A good example is a String or some sort of Error type on a function that does some sort of computation. If the computation succeeds, return a String, otherwise, an Error.
3) (Similar to the point I made above) Facilitating an alternative to overloading. If you have a function that can take as one of its parameters either a String or an Integer, instead of having two separate functions with different logic, write one function with a union type with conditional logic on the union type inside the function.
4) Enumerated types or algebraic types. By intentionally limiting the subtypes of a type hierarchy, it's possible to, for instance, limit the case statements within a switch and not have to assert the default case isn't selected, for example.
5) Collections and other generic containers can be more flexible by explicitly denoting and limiting the possible types with a union. I can invoke the function in example 2) and get back a series of unions of String or Error, making this transparent to the type system and the reader of the code.
6) Eliminating a whole bunch of boilerplate in typical Java-style class hierarchies.
What's more Microsoft has added union types to TypeScript: https://github.com/Microsoft/TypeScript/issues/805, and Flow (a static type checker for JavaScript) has added them as well: http://flowtype.org/docs/getting-started.html#_
By the way, I just read that Swift has union types, but they are called enums.
By the way, I just read that Swift has union types, but they are called enums.
Not the same thing.If you read this, you'll understand:
http://ceylon-lang.org/documentation/1.1/tour/types/
Your comments about type safety and convenience are valid. So your right it has additional value to have optionals in a language.
But to answer your question: create a class StringIntegerUnion and subclasses StringFromStringIntergerUnion and IntegerFromStringIntegerUnion.
That will make it completely type safe and absolutely clear to read and will give no runtime errors.
In general I think it's not a good idea to think in terms of unions made of basic types, most code should not need that.
I fail to see the difference (did you take 'associated values' in account)?
Can you give an example what you can't do with Swift enums (with associated values) that you can do with optionals?