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? 

Wednesday 12 March 2014

State of affairs in programming for Mobiles - an opinion!

I think that we are slowly getting used to the fact that most people do most of their work now on non-desktop devices. In fact, on a recent trip away, my laptop stopped charging and I was left to look after server management and a few database bugs on nothing but tablet and phone. Thanks to 4G for that one!

However, as mobile devices (including tablets) become more ubiquitous, this means that developers are having to learn new skill-sets or broaden existing talent. The following information is just a quick summary of information and opinions that I am forming with regard to mobile development.

Choices
When you take on a new project for mobile devices, the first thing that you are likely to have to decide from a programmatic point of view is whether to have a single code base or to write more natively for each device.

To explain: iOS uses the increasingly popular Objective-C as a native language. Whereas Android uses Java. I'm not sure about Blackberry as I have never had any one ask for an app, however, it seems as though c++ would probably be the language of choice for that. The benefit is that you can write straight for the intended operating system and will have full access to the SDKs and APIs that make development easier on those platforms. At present, for the scale of apps that I develop, this is the weapon of choice for me.

Alternatively, you can write non-native code that accesses the APIs indirectly. Perhaps the best example that caught my eye was Xamarin, primarily because it allows you to write code in c#. The obvious benefit is the re usability of code. The write once, use anywhere syndrome that made Java popular. Other companies do have similar libraries (another notable c# entry is DevExpress).

So the question is, why do I still use native code rather than cool 3rd party frameworks that allow you to write a common set of libraries?

Firstly, cost is a big thing. A lot of these libraries ask for large lump sum payments and/or subscriptions. When developing, I am rather scrooge like and will try to get anything that I can for free before I go to the paid option.

Secondly, I am quite thick and I found that with the small amount of time that I have spent on learning native languages vs learning c# for Xamarin or DevEtreme, I actually progressed quicker learning a new language. I find that the Data Access and common tasks are far more simple to learn from the docs of the native languages and I really love the MVC way that Objective-C utilizes! (but that's for another post me-thinks).

Finally, I have bad experiences with write once libraries. Without going too deeply into the reasons (again another post's job), I have found that there are a lot of issues and bugs that you simply don't get in native libraries that transfer to non-native libraries. This is certainly true of desktop equivalents and I have found similar sentiments regarding the mobile libraries that has put me off for now. What I really don't want is to be promised a write once scenario only to have to continually put "if" statements or other conditional branching for each operating system. I actually would prefer to write it all again (but with the logic already in mind) than to do that.

Again, this post is highly subjective and some of you may find different scenarios work for you than what I have outlined above. If you have any comments, please feel free to comment below and tell me where I am wrong.