Earlier quoted context omitted.
WWDC app.
They said they made a version of it in Swift. The actual version deployed on the App Store was written in Objective-C.
Are you sure? That's not what I heard, but I could be wrong.
My Swift Dilemma
101–110 of 129 posts
Re: My Swift Dilemma
#102Earlier quoted context omitted.
You're the one who evoked "blub", essentially insinuating that the reason for his inability to appreciate the language was due to him not being used to it. I addressed that, and your counter with that it's "hard to make a programming language"? Of course it's hard. And the problem with Swift is that it tried to do so many things at once, even with the hard constraints it had. And this is precisely why the language en…
You're putting words in my mouth. I did not say "it is hard to make programming languages". It is a skill like any other that can be improved with sustained practice. My point is most of these conversations about the merits/demerits of languages are less than useless. Here's a programming language checklist http://colinm.org/language_checklist.html and another one about the history of programming languages http://jam…
Regarding "blub" I already told you that this is unlikely given the amount of dialog and work Owens has done in the language so far.
He is one of the few people who has written in depth about the language (not tutorials)
If you didn't like my attempt to make sense of your non-sequitor about programming languages, you should perhaps reconsider your approach to commenting / writing.
In any case, his post is to be understood as a "current feelings about Swift" after writing code and blog articles about different features in Swift, starting with this one http://owensd.io/2014/06/09/swift-future-for-app-developers....
Just saying that he is pulling opinions out of the blue ("not really interested in any kind of deep analysis") is blatantly false, as his other articles IN THAT BLOG amply demonstrates.
Re: My Swift Dilemma
#103Earlier quoted context omitted.
You're the one who evoked "blub", essentially insinuating that the reason for his inability to appreciate the language was due to him not being used to it. I addressed that, and your counter with that it's "hard to make a programming language"? Of course it's hard. And the problem with Swift is that it tried to do so many things at once, even with the hard constraints it had. And this is precisely why the language en…
You're putting words in my mouth. I did not say "it is hard to make programming languages". It is a skill like any other that can be improved with sustained practice. My point is most of these conversations about the merits/demerits of languages are less than useless. Here's a programming language checklist http://colinm.org/language_checklist.html and another one about the history of programming languages http://jam…
>Regarding "blub" I already told you that this is unlikely given the amount of dialog and work Owens has done in the language so far. He is one of the few people who has written in depth about the language (not tutorials)
Well, if said post is anything to go by, that's not saying much...
Re: My Swift Dilemma
#104Earlier quoted context omitted.
You are right, without additional information property testing would be less useful. Which is yet another reason to favor static typing in my opinion.
There are degrees of static typing. Swift tries to get close to Haskell, but without the full set of tools to do so without losing things along the way. This is sort of the worst of both worlds. In the meantime Strongtalk already demonstrated that you can write a fairly rich optional type system to reap the compile time benefits of static typing while retaining the runtime power of message passing. I think that would…
Why do you say it is the worst of all worlds? To me it is a very good compromise and about as good a situation as you can get while maintaining C/Objective-C compatibility. Don't forget there are performance benefits to being less dynamic (not using runtime message passing) and you can opt in to that runtime mode if you want by making classes @objc.
Re: My Swift Dilemma
#105Earlier quoted context omitted.
My favourite part was the whole "Optionals suck because Obj-C have nil, therefore Obj-C is superior" bit.
Except for the "therefore Obj-C is superior" part, I agree that Option types in languages such as Swift and Scala are unfortunately marred by those languages' need to be compatible with Obj-C and Java, respectively. I understand idiomatic Scala won't use null , just as I assume idiomatic Swift won't use nil , but nevertheless the fact that they allow nulls weakens their type systems.
Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is the optional counterpart. This is just the same as using the Maybe monad in Haskell and can be reimplemented in that way. Do you think that this also weakens Haskell's type system?
Now if your issue was with the "!" Operator I would say that there is a case to be made but that should be used sparingly and carefully and is an obvious place for additional code review.
Re: My Swift Dilemma
#106Earlier quoted context omitted.
Yes, I've heard it many times. How is that a counterexample? Bizarre syntax alone is not enough for the Blub paradox. I don't know anyone who seriously argues that Obj-C is a more advanced language than Java/C++, so Blub doesn't apply.
You should get around more. Objective-C object-orientation via dynamic messaging is much more advanced/powerful than the Abstract Data Types available in C++ and Java. It enables such features as target/action, NSUndoManager, Higher Order Messaging, distributed objects...and their concise implementation. If you don't understand dynamic messaging and see Objective-C as just a way of doing things that you would do in J…
This is entering highly subjective territory.
The consensus is that Objective-C's brand of OO is not particularly advanced, and Objective-C as a language is definitely not considered advanced. Keep in mind Paul Graham's essay had Lisp in mind, not a C derivative.
Nevertheless, the post that sparked this thread was a comparison between Swift with Obj-C. Now, even if you consider Obj-C an "advanced language" (which most people do not), it's completely unreasonable to think that a programmer looking at both Swift and Obj-C would disregard the latter because of the Blub paradox. It would be highly... let's say nonstandard to consider Obj-C more advanced than Swift.
Not Blub.
Re: My Swift Dilemma
#107Earlier quoted context omitted.
Except for the "therefore Obj-C is superior" part, I agree that Option types in languages such as Swift and Scala are unfortunately marred by those languages' need to be compatible with Obj-C and Java, respectively. I understand idiomatic Scala won't use null , just as I assume idiomatic Swift won't use nil , but nevertheless the fact that they allow nulls weakens their type systems.
Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is the optional counterpart. This is just the same as using the Maybe monad in Haskell and can be reimplemented in that way. Do you think that this also weakens Haskell's type system? Now if your issue was with the "!" Operator I would say that there is a case to…
Hmm, maybe Swift's Optional works differently to Scala's Option, in which case my objection can be dismissed.
In Scala, you can declare a value to be of type Option[T], which means it will be either a Some[T] or a None. This looks superficially like Haskell's Maybe monad.
val x: Option[Int] = Some(1)
val x: Option[Int] = null
Can a similar example be written with Swift? I assumed it was possible, but maybe I'm mistaken.
Re: My Swift Dilemma
#108Earlier quoted context omitted.
You are right, without additional information property testing would be less useful. Which is yet another reason to favor static typing in my opinion.
There are degrees of static typing. Swift tries to get close to Haskell, but without the full set of tools to do so without losing things along the way. This is sort of the worst of both worlds. In the meantime Strongtalk already demonstrated that you can write a fairly rich optional type system to reap the compile time benefits of static typing while retaining the runtime power of message passing. I think that would…
Yes, there are degrees of static typing (hence, some people unfortunately disregard great type systems because they are only familiar with Java's cumbersome one).
The thing is, as soon as you realize that unit testing (of the kind proposed by 3+4=7) alone is not enough, or even adequate, and that you must use more advanced tools, and that more advanced tools can and should be automated whenever possible... you will probably start considering the possibility that static typing was a good idea after all. Especially if you were considering using type annotations in your dynamically typed language because you needed to extra info in order to use more advanced testing tools.
Static typing is an incredibly useful automated verification that the compiler performs for you, freeing you to write more interesting tests. It won't catch all mistakes, but no-one is arguing that any single technique will. The argument is about the relative merits of "unit testing alone is enough" vs "testing + automated testing with type checking is way better".
Re: My Swift Dilemma
#109Earlier quoted context omitted.
Can you explain more about what you mean by Swift allowing nil weakening it's type system? Swift types don't allow nil but you can use a different type that is the optional counterpart. This is just the same as using the Maybe monad in Haskell and can be reimplemented in that way. Do you think that this also weakens Haskell's type system? Now if your issue was with the "!" Operator I would say that there is a case to…
Hmm, maybe Swift's Optional works differently to Scala's Option, in which case my objection can be dismissed. In Scala, you can declare a value to be of type Option[T], which means it will be either a Some[T] or a None. This looks superficially like Haskell's Maybe monad. val x: Option[Int] = Some(1) The problem with Scala is that you can also write something like this: val x: Option[Int] = null By declaring a value…
In Swift nil is the value equivalent to Haskell's None so there is no distinction there which I think you are saying that there is in Scala.
Swift does have "implicitly unwrapped optionals" which you declare with "!":
var x:Int! = nil
rather than normal optional syntax of
var x:Int? = nil
It does weaken the type system and I would only make very limited use of it. I would only ever use it for properties that will not be nil after the initialiser has finished. Even though there is a way around the type system to do dangerous things I think it is still far better to have the type system there and to only work round it when absolutely necessary than to default to something much weaker. As I've mentioned elsewhere "!" is a code smell and I would use it rarely and audit those places heavily.
Re: My Swift Dilemma
#110Earlier quoted context omitted.
I know that's just an example and that you probably don't actually write tests like that in your day job, but it's a terrible unit test. For example, it fails to tell apart addition from the constant function 7. Even if you add more data points, you're still not testing addition. In a way, "testing for specific values" is very misleading. Consider that it'd be the wrong if you were actually trying to prove something.…
> it fails to tell apart addition from the constant function 7 It's not supposed to do that. Have you heard of TDD? In a TDD/XP setting, the constant function 7 would be the appropriate implementation for making that test pass, because it is the simplest thing that could possibly work. Then you add another test, let's say add(40,2) EXPECT(42). Now you could extend your add() function to do case analysis, and maybe in…
I'm familiar with TDD, both its strenghts and limitations (http://ravimohan.blogspot.com.ar/2007/04/learning-from-sudok..., http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driv..., etc).
I understand that this kind of testing often works (though I'm less enthused with TDD as a design technique, which is unfortunately what TDD proponents emphasize, and what you seem to be describing here). I'm saying it is too limited. "But software is written and tested this way", you can say. But buggy software is written every day, even with testing, which is why we should strive to improve our testing tools & processes.
To be clear I'm not saying "abandon TDD" (ok, maybe I'm not rooting for TDD in particular, but I'm definitely not saying "abandon unit testing"). What I am saying is "complement it with static typing and more advanced testing techniques, such as property testing."
Finally:
>> it fails to tell apart addition from the constant function 7
> It's not supposed to do that.
Well, in a way it is. Your tests must attempt to detect flawed implementations, even though they cannot prove correctness. I'm sure you can think of cases where an algorithm sometimes seems to return the correct result, but fails in some cases.