If your skills are locked in to a certain language then you're doing it wrong.
The only person who can make your skills transportable is yourself.
Learn open source and proprietary technologies alike, now you become someone with a lot of diverse skills.
This open source fanboyism makes no sense if you want to be professional about your craft.
Generally, the open technologies were proved to be useful in long-term, and even when they change, they change evolutionary. You don't have big bumps and complete u-turns in your progress.
There is also no-one, who suddenly decides that the technology you were invested into is suddenly not profitable for them and ceases development. The open source technologies die only then, when they are not useful to anyone.
So basically, strong preference for open technologies is a pragmatic risk mitigation and investment protection.
> So basically, strong preference for open technologies is a pragmatic risk mitigation and investment protection.
.net and Microsoft technologies completely invalidate that claim, don't you think?
Coupled with the amazing NeXTBSD work that's spun up, I've found myself surprisingly excited about what Swift might become.
So go pick OCaml, Haskell, Rust, Idris,.... instead.
A question for the more switched-on among us: has there been any word on when Swift 2 will be open-sourced?
No official word from Apple though.
If you or anyone wants to read flagged comments or comments killed for any reason (other than the author deleting them), you can set 'showdead' to 'yes' in your profile.
The way I see it, the comment received a warning because it was contentless and offensive without reason. Does there need to be more context?
Anyway, let's hope the developer community jumps onboard for the ride. For anyone interested in learning Swift, I've accumulated just under 1800 Swift urls in the past 15 months:
//Warning if you don't use let :-)
let array = NSMutableArray(capacity: 50)
However, what I am saying is that Apple needs to somehow add the keywords to the container classes imported from Cocoa, this is manually I guess.
I wonder if adding a mutating keyword on the declaration would help
public mutable func addObject(anObject: AnyObject) mutable
If you're wondering why I am using CFArray -> performance.
Structs are pretty slow since you'd have to copy it from the dictionary to mutate and then insert into the dictionary again.
Though, those numbers were with Swift 1. Will try with Swift 2 again, but given the nature of immutability, I suspect it will still be slower.
Now that I think about it. I might make my own generic structs that uses NSArray/NSDictionary internally. Though I wonder if you can pass structs by reference instead of copy, that would be more useful.
An Array<T> is a struct but uses a storage reference type under the covers. In theory the standard library is actually free to make common slices of arrays share storage so pure additions don't even require copying but I have no idea if it is actually implemented that way (neither String nor Array guarantee contiguous storage)
I think Swift could greatly enhance its power in the functional paradigm if indeed it did what you describe, but also making this clearly known to everyone who uses it.
Heck, even Java (using final to mark immutable) would work like this. This is basically how every OO language works.
That said, it's a quirk of the interop and I don't think Apple should spend time fixing it - rather developers should avoid NSArray within Swift.
let a = Foo()
Naturally, that would be manual work though. Like the way they added nonnull, nilable or whatever its called to Obj-C
The "bug," if there can be said to be one at all (I don't see it), is that Swift collection types are value types, while Objective-C collection types are reference types. But given this difference, the lack of `mutating` on the mutating methods makes complete sense, and adding it would be bizarre, since it would be an error if you did it in your own code.
I haven't done selectors yet partially because I use relatively few of them and partially because parsing code is slightly harder than file system walks and xml parsing.
I would like to see Swift eventually become a general purpose programming language useful outside of Apple's niche but it's got enough baggage from its ties to UIKit & ObjC I'm not sure how likely this is to happen.
But do editors highlight this properly? (JOE 4.1 does).