About Swift, and why my big projects will be on Objective-C for some (maybe long) time
From the translator: C Friday, dear habrovchane! Today I want to share with you a translation of an article from a small blog about experience with the Swift language. It is unlikely that she claims the laurels of a serious and scrupulous analysis, but I think it will be interesting to anyone who thought: “Isn't it time to send this Objective-C to the dustbin of history?”.
When Apple introduced Swift to us - that was awesome! Finally, we got the next-gen (i.e. trendy-script-like) language for developing for apple devices (but without the support of the private members of the class, hmmm ....). Now this [the language of the square dinosaur] can go to the museum, and we will begin to poke these new shiny features of the language. It is certainly naive to assume that a language that is less than a year old will be without cockroaches. Obviously, some time needs to be given to him to get rid of childhood sores. That is why I did not rush to rewrite all my projects on Swift immediately after the announcement.
Noticed that the bird is falling down?
')
A year after graduation, I finally decided to learn the language. For this, I began to write a toy about the most terrible thing in the world (in the world of Windows 3.1, okay) - a monster from the game SkiFree. You can read about it here.
Disclaimer : I write about one year old sweater. I'm sure the guys from Apple will fix all these problems, and the language will become a very elegant tool. Well, either a slow-moving behemoth after XCode 7.
Let's go back to Swift. One night with the book “The swift programming language” and I am ready for accomplishments. The language fascinated me with its simplicity, the transparency of constructs, and the hidden power to write safe code (and yes, they added private members to classes). I started writing a SripteKit toy and ...
Is this serious? My Objective-C project with 60 thousand lines is only two times longer than my 600-line Hello World on Swift. Suddenly, I remembered those glorious times (actually it was just a few months ago) when I was working on a huge project, and the picture below described some working days beautifully:
This undocumented language feature was very unpleasant to me: I developed a small toy and often changed some hard-coded values ​​with small pieces of logic quite often. And every small change required rebuilding the project. Yes, I know that this problem can be solved in many ways, for example, by putting constants in configs or by creating an in-game debug menu. But all these approaches required additional efforts, and I would prefer to focus on my main task: creating a small funny game.
In the end, a person can get used to anything. But the compiler hit me again:
Uh ... Can't add up two floats ... well ...
For those of you who are already sharpening their knives, to wean this monkey coder from working with hardcodes and using simultaneous float and double types in the code, I want to say: first, CGFloat came to me from UIKit, and double from third-party code . So this is not a very exotic situation when you have to mix these two types. And the removal of hardcoded values ​​in the constants would help the code to become more sensible, but this is unlikely to save from the amazing progress of the compiler. Of course, this bastard can add up two floats - the fact is that he hides a real problem from me!
You know, I always perceived the compiler as something like the old wise Gandalf, who explains to the stupid hobbits how the world really works.
Sometimes it is difficult to understand what this old man carries. But if you think about it, it really points to the problem. Continuing the metaphor, the Swift compiler, telling me about the problem with the summation of two floats, reminds me more of this sticky movie from The Hobbit.
Black ritual over the code, and finally he earned. Here is the injected version:
I did not remember every such incident during the development, but these, I think, are enough to illustrate my idea.
Another problem associated with the first is the low rate of static analysis in comparison with Objective-C. There was a time when I turned off syntax error highlighting in XCode in real time, since I wrote the code much faster than XCode had time to analyze it (man versus machine: 1: 0, ho-ho). The clues just annoyed me. With the purchase of a new poppy, the analysis became almost instantaneous - and with great pleasure I began to use this feature. But with Swift, I again met the same problem (2: 1. Man wins).
And finally, the pearl of my collection:
I have seen a lot in my life ...
I’ve seen compiler optimizations that compromise performance due to the inserted if (0) {...} expressions
I have seen monstrous bugs related to the missing 'volatile' keyword
I have seen how terrible destructions can be caused by indefinite language behavior.
But I have never seen a compiler complaining about its hard life.
This message would be very useful if it were a warning. But this is a critical error. So yes, you have to simplify this expression. I would understand this situation if this error got out for a very long construction. But my expression was less than 120 characters long. For some developers, this situation may seem normal, but I was raised with wolves in C / C ++ languages ​​and an x86 assembler. So for me it looks weird.
What is the bottom line? We got a language similar to trendy Python / Go / Ruby. But is there any reason to start a big project on it?
Generics? Yes, it is very good, but Objective-C also now has generic support (yes, ugly, but there is). And the guys from Go generally say that they are fine without generics.
Optional types? In my opinion, this is a very controversial concept. It is very convenient if we are discussing passing arguments to functions, but it can be painful when it comes to class members who may be uninitialized for a long time (for example, in the case of lazy initialization).
Passing objects by value? If you need productivity, then C / C ++ is at your service. If you also want to use optional values, then, of course, in C / C ++ it will look a bit ugly, but, nevertheless, possible.
So epl. Well, seriously, it looks like you created a language just because you were laughed at because of the square brackets (! (“Write the code, as if spoken in English”, heheh) and YES / NO in Boolean. And what is the price? Now We are a language with a slow build and, at times, a very strange behavior of the compiler.
So the old man said everything he wanted. But you, fans of fashionable, script-like languages, should not take my words too close to my heart: in fact, Swift is a good language with a good design. All the gaps that I have described can be started without significant changes in the language, so that once they are gone. Swift is a great language for writing Hello World, but I don’t recommend to start large projects yet.
When Apple introduced Swift to us - that was awesome! Finally, we got the next-gen (i.e. trendy-script-like) language for developing for apple devices (but without the support of the private members of the class, hmmm ....). Now this [the language of the square dinosaur] can go to the museum, and we will begin to poke these new shiny features of the language. It is certainly naive to assume that a language that is less than a year old will be without cockroaches. Obviously, some time needs to be given to him to get rid of childhood sores. That is why I did not rush to rewrite all my projects on Swift immediately after the announcement.
Noticed that the bird is falling down?
')
A year after graduation, I finally decided to learn the language. For this, I began to write a toy about the most terrible thing in the world (in the world of Windows 3.1, okay) - a monster from the game SkiFree. You can read about it here.
Disclaimer : I write about one year old sweater. I'm sure the guys from Apple will fix all these problems, and the language will become a very elegant tool. Well, either a slow-moving behemoth after XCode 7.
Let's go back to Swift. One night with the book “The swift programming language” and I am ready for accomplishments. The language fascinated me with its simplicity, the transparency of constructs, and the hidden power to write safe code (and yes, they added private members to classes). I started writing a SripteKit toy and ...
Is this serious? My Objective-C project with 60 thousand lines is only two times longer than my 600-line Hello World on Swift. Suddenly, I remembered those glorious times (actually it was just a few months ago) when I was working on a huge project, and the picture below described some working days beautifully:
This undocumented language feature was very unpleasant to me: I developed a small toy and often changed some hard-coded values ​​with small pieces of logic quite often. And every small change required rebuilding the project. Yes, I know that this problem can be solved in many ways, for example, by putting constants in configs or by creating an in-game debug menu. But all these approaches required additional efforts, and I would prefer to focus on my main task: creating a small funny game.
In the end, a person can get used to anything. But the compiler hit me again:
Uh ... Can't add up two floats ... well ...
For those of you who are already sharpening their knives, to wean this monkey coder from working with hardcodes and using simultaneous float and double types in the code, I want to say: first, CGFloat came to me from UIKit, and double from third-party code . So this is not a very exotic situation when you have to mix these two types. And the removal of hardcoded values ​​in the constants would help the code to become more sensible, but this is unlikely to save from the amazing progress of the compiler. Of course, this bastard can add up two floats - the fact is that he hides a real problem from me!
You know, I always perceived the compiler as something like the old wise Gandalf, who explains to the stupid hobbits how the world really works.
Sometimes it is difficult to understand what this old man carries. But if you think about it, it really points to the problem. Continuing the metaphor, the Swift compiler, telling me about the problem with the summation of two floats, reminds me more of this sticky movie from The Hobbit.
Black ritual over the code, and finally he earned. Here is the injected version:
I did not remember every such incident during the development, but these, I think, are enough to illustrate my idea.
Another problem associated with the first is the low rate of static analysis in comparison with Objective-C. There was a time when I turned off syntax error highlighting in XCode in real time, since I wrote the code much faster than XCode had time to analyze it (man versus machine: 1: 0, ho-ho). The clues just annoyed me. With the purchase of a new poppy, the analysis became almost instantaneous - and with great pleasure I began to use this feature. But with Swift, I again met the same problem (2: 1. Man wins).
And finally, the pearl of my collection:
I have seen a lot in my life ...
I’ve seen compiler optimizations that compromise performance due to the inserted if (0) {...} expressions
I have seen monstrous bugs related to the missing 'volatile' keyword
I have seen how terrible destructions can be caused by indefinite language behavior.
But I have never seen a compiler complaining about its hard life.
This message would be very useful if it were a warning. But this is a critical error. So yes, you have to simplify this expression. I would understand this situation if this error got out for a very long construction. But my expression was less than 120 characters long. For some developers, this situation may seem normal, but I was raised with wolves in C / C ++ languages ​​and an x86 assembler. So for me it looks weird.
What is the bottom line? We got a language similar to trendy Python / Go / Ruby. But is there any reason to start a big project on it?
Generics? Yes, it is very good, but Objective-C also now has generic support (yes, ugly, but there is). And the guys from Go generally say that they are fine without generics.
Optional types? In my opinion, this is a very controversial concept. It is very convenient if we are discussing passing arguments to functions, but it can be painful when it comes to class members who may be uninitialized for a long time (for example, in the case of lazy initialization).
Passing objects by value? If you need productivity, then C / C ++ is at your service. If you also want to use optional values, then, of course, in C / C ++ it will look a bit ugly, but, nevertheless, possible.
So epl. Well, seriously, it looks like you created a language just because you were laughed at because of the square brackets (! (“Write the code, as if spoken in English”, heheh) and YES / NO in Boolean. And what is the price? Now We are a language with a slow build and, at times, a very strange behavior of the compiler.
So the old man said everything he wanted. But you, fans of fashionable, script-like languages, should not take my words too close to my heart: in fact, Swift is a good language with a good design. All the gaps that I have described can be started without significant changes in the language, so that once they are gone. Swift is a great language for writing Hello World, but I don’t recommend to start large projects yet.
Source: https://habr.com/ru/post/270291/
All Articles