Just how similar is Swift to leading JVM languages like Java and Groovy? And what are its prospects for becoming mainstream? Coding trainer Guilherme Silveira gives his two cents.
When it comes to Swift, there are comparisons with all languages. As someone once said: “Ruby devs will say: Ruby. Scala devs: Scala. Groovy devs: Groovy. Java devs: what is a closure?”
It’s a funny joke. But there’s one simple mistake here: the phrase is talking about syntax. Code (and good code) is not about syntax. It’s about long term productivity.
We all love those images that show languages empowering productivity for young developers. The only problem is, we don’t see many the scientific reports with control tests showing that they are more productive in the long term, such as after two years of coding.
The few scientific reports are typically restricted to the academia universe of exercises (testing simple program development, course exercises) or short term (one semester or one year). None of which is the reality of our daily life: playing with code from ten developers that came before us in the previous two years.
Language history is long: every language can be used to make a successful product. We know that from the ‘Mythical Man Month.’ No silver bullet. Everything has its niche.
Of course, Swift is way less verbose than Java, but it has several features from it, as it does from any of those JVM languages you might care to mention.
Java does allow you to create and use good citizens – something that we have been evangelizing for years, but mainstream frameworks from almost every language out there point to the opposite direction: everything is dynamically injected after construction – good luck with those mutable values. Then we complain that is a language issue. Then we switch languages, and the cycle repeats. That’s why I think the optionals default solution for Swift is so amazing, they really did something that mainstream languages did not, while sticking to trying to be mainstream.
So we are not talking about syntax, software development is not a championship à la typeracer, or who types less, or who does the most cryptographic code. It is not about compressing content (and thus making it more ambiguous, something that we can’t fight against). The language structures presented in Swift are amazing not because it was based in other languages, but how they connect to each other.
Still, there is space for the language to growth. To date, reflection is hard and dealing with several error conditions in a real life application is not yet an easy thing to do. That should not be a problem, as Brian Goetz points out, every language has added crappy features at some point in their life. If Swift can avoid doing so, we might have a new mainstream language. So far, in the space, apart from Java, C# and even PHP, a few others do seem to have got things right to stay mainstream. A simple Google search gives an idea of their influence in our market, and thus the world.
Summing up, Swift is similar to all those languages as it is grounded in common concepts, but it really stands out out when dealing with optionals. I hope we finally get invalid memory pointers right, but it seems !? might not allow us to do so.
Note: To be fair, there are situations where we need optional values, those are exceptional moments… so I guess, the next question is, how should we deal with exceptions in Swift?
I love Swift for what it allows us to do, and hopefully Apple will allow us to get rid of some of the language features that disrupts our ability to be sure that our code works. The same way that Groovy provided annotations to compile time check if our code is right, or Facebook’s Hack provides levels of compile time validation.
That is what I, as a teacher and developer, care about; being sure that me and my students’ code runs as we expect, and being sure that maintenance is cheap and good. We have to wait a couple of years and see if our Swift code will have fewer errors while avoiding using optionals. The final problem is: the API and drag+drop forces us to use them. Who will win the fight?