Monday 4 August 2014

Thoughts on Swift programming language

I'm going to refer back to the last post about the state of mobile device development. I mentioned that Objective-C is the iOS default. I also stated that in my opinion, the native code is the best way to go for both iOS and Android. I have a little attachment that I would like to add to that statement, as it has bearing on the rest of this article. 

Both iOS and Android have easy ways to utilise a c++ library. The benefit is fast, multi-use libraries for things such as the DAL (data access layer). Swift has a workaround (some may argue that Android is a bit of a workaround too). But let's start at the beginning. 

Swift is a new language that Apple have released among an exciting amount of changes to their desktop AND mobile operating systems.  The syntax looks very Javascript meets Python and from the limited experience I, and all other developers outside of Apple, have, seems to be reasonably sensible in syntax too. 

First the positive. I have never really been a fan of Objective-C. I like the fact that it forces MVC as I really need to be forced in order to avoid falling into bad practices, but I really don't like the amount of time that I spend writing brackets, a practice slightly more galling than writing parentheses. Therefore, a more "C-esque" approach to the syntax was, for me at least, a welcome change. 

Apple also state that the code runs a lot faster, therefore, it seems that you are less likely to NEED to use C++ for games and other intensive applications just based on C++'s performance.

But what about the bad? There seems to be an inherent difficulty in producing a language and making it the default standard of a well used operating system: No-one knows it! Therefore, all of your developers are going to clog up stack overflow, fumble around for a while and then, unless it really is the bees knees, move back to what they were using before.

Also, if I want to change some legacy code, I need to do so in Objective-C. Now one could argue that this is what has happened to a lot of languages, I'm looking at your FORTRAN and COBOL. However, in order to really relegate Objective-C to COBOL's status, Swift would have to be such a good language, I just don't see that it makes THAT much difference. 

Another consideration is one mentioned in the prologue of this post. Objective-C is like a C++ wrapper for people with bracket fetishes. This meant that if you wanted to plug in a C++ library, then you just had to do it in the normal C++ way. However, with swift, you have to have an intermediary Objective-C header that doesn't directly contain any C++ files, otherwise Swift won't allow it. #iscplusplusdying

As mentioned at the outset, I had just found the ideal solution to the native/interpreted dilemma on mobile development, and now it looks as though I will have to "work around" the issue. This makes me an unhappy puppy. 

However, I am still overall undecided if Swift is a good idea, an abomination or something in between. Maybe any "experienced" Swift devs could comment and let me know their thoughts? 

No comments:

Post a Comment