When I recently interviewed at Apple I was told my position would primarily be coding in Java, but the team would be open to other languages as the project progressed and needs changed. I asked if they would consider Swift. Then was told that Swift wasn't production ready in their eyes. (I didn't get the job) I guess every team is different, but this attitude to dog fooding isn't great.
I interviewed at IBM for a position making Enterprise template apps for iPad working directly with Apple, and the main reason they said they passed on me was while I had a good amount of Objective-C experience, I had only dabbled with Swift on my spare time and had difficulty answering a couple of the questions they grilled me on in Swift. They specifically said I should have had more professional Swift experience wh…
IBM says Swift is ready for the enterprise
211–220 of 235 posts
Re: IBM says Swift is ready for the enterprise
#212Earlier quoted context omitted.
Using their weight, huh. Apple hit 10% market share with the Mac for the first time in 2012. I think it's something like 15% now.
Do you think laptops are the dominant computing device?
Re: IBM says Swift is ready for the enterprise
#213Earlier quoted context omitted.
I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a…
Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.
On my computer, recent versions of AppCode constantly use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.
I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.
There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).
It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.
Re: IBM says Swift is ready for the enterprise
#214Earlier quoted context omitted.
I said it can, not that it does it already. My Swift experience is constrained to the GNU/Linux version, so I don't know if XCode is already doing something in this direction. Sure one can have blessed library types that the compiler knows about, but then from language design point of view it creates a decision between those types and others written by developers, but with similar semantics.
Since you said it's easier than these other languages, I thought you were referring to how the languages work now. There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optio…
Thanks for clarifying.
Re: IBM says Swift is ready for the enterprise
#215Re: IBM says Swift is ready for the enterprise
#216Earlier quoted context omitted.
Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it. I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).
You don't need in/out params to get references; in Swift, anything defined with "class" is always passed by reference.
Re: IBM says Swift is ready for the enterprise
#217Earlier quoted context omitted.
Since you said it's easier than these other languages, I thought you were referring to how the languages work now. There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optio…
Sure, I was more thinking about the language geek point of view. Thanks for clarifying.
Re: IBM says Swift is ready for the enterprise
#218Earlier quoted context omitted.
I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a…
Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.
Re: IBM says Swift is ready for the enterprise
#219When I recently interviewed at Apple I was told my position would primarily be coding in Java, but the team would be open to other languages as the project progressed and needs changed. I asked if they would consider Swift. Then was told that Swift wasn't production ready in their eyes. (I didn't get the job) I guess every team is different, but this attitude to dog fooding isn't great.
I interviewed at IBM for a position making Enterprise template apps for iPad working directly with Apple, and the main reason they said they passed on me was while I had a good amount of Objective-C experience, I had only dabbled with Swift on my spare time and had difficulty answering a couple of the questions they grilled me on in Swift. They specifically said I should have had more professional Swift experience wh…
Re: IBM says Swift is ready for the enterprise
#220Does this loosely translate to "We want to sell Swift consulting services to the enterprise"?