3 ms·

"Swift wants to be a "big" language" My guess is that it is not ideological. Swift feels like it wants to be 'everything'. Because of this, it's almost too mu

"Swift wants to be a "big" language" My guess is that it is not ideological. Swift feels like it wants to be 'everything'. Because of this, it's almost too much. I want to like Swift, but I run into a lot of trouble with it. The decision to be compatible with ObjC was one of the big issues: obviously, pragmatically, they felt that they just had to do it. In hindsight, I wonder if it would have been better to just have a clean break.

fiedzia 10y ago
> In hindsight, I wonder if it would have been better to just have a clean break. Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.
- edblarney 10y ago
  Yes, that is the rationale. But I wonder. They are a $700B company. What if they just 'did it right' - i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC. Because the 'fallback on ObjC' has more problems than integration. A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example. Swift could have been an easy-to-approach language. But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' - you still had better know a lot of ObjC! So - to really make use of 'the new' - you still have to know 'the old' - which totally defeats the purpose! I wish they had made a clean break - great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.
  - fiedzia 10y ago
    > They are a $700B company. But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford. > What if they just 'did it right' You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices. > A lot of people want to make apps for iPhone and ObjC is not in their vocab. And even more has existing apps to maintain. Tradeoffs have to be made. > great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes All those things will come. If you want them, wait for them. Being early adopter has its cons.
    - edblarney 10y ago
      "Lot of them have no budget (or will) for complete rewrite. " I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it. Also - Apple could feasibly provide a 'lib/bridge' - just as Android can use C++ code as well, if you want to use it. I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support. "All those things will come. If you want them, wait for them." I don't agree - this is 'doing it wrong'. It's been out for years. This is way past 'early adoption'. 'Doing it right' means that it is easy for new and old developers. Right now - it's hard. Doing Swift 'right': 1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC. 2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'. 3) Beta for 1 year, then production. 4) No backwards-incompatible changes after out of beta. (Easier said than done). 5) Docs, examples etc that clearly demarcate versioning. 6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange. 7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff. 8) Free online courses, for newbs, and those coming from other languages, and Objc. They made Swift a little too complicated, and left devs hanging in the dark on so many issues.
      - fiedzia 10y ago
        > I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions? > It's been out for years. This is way past 'early adoption'. Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape. >Make Swift a clean break, get rid of some of the more obscure things that make it difficult. If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in. I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.
mpweiher 10y ago
>compatible with ObjC was one of the big issues Considering that was going to be hard requirement, maybe the problem was introducing so many things that are so incompatible with ObjC? There are tons of ways you could vastly improve the programming experience without introducing all this incompatible stuff.

fiedzia 10y ago

> In hindsight, I wonder if it would have been better to just have a clean break. Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.

edblarney 10y ago
Yes, that is the rationale. But I wonder. They are a $700B company. What if they just 'did it right' - i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC. Because the 'fallback on ObjC' has more problems than integration. A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example. Swift could have been an easy-to-approach language. But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' - you still had better know a lot of ObjC! So - to really make use of 'the new' - you still have to know 'the old' - which totally defeats the purpose! I wish they had made a clean break - great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.
- fiedzia 10y ago
  > They are a $700B company. But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford. > What if they just 'did it right' You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices. > A lot of people want to make apps for iPhone and ObjC is not in their vocab. And even more has existing apps to maintain. Tradeoffs have to be made. > great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes All those things will come. If you want them, wait for them. Being early adopter has its cons.
  - edblarney 10y ago
    "Lot of them have no budget (or will) for complete rewrite. " I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it. Also - Apple could feasibly provide a 'lib/bridge' - just as Android can use C++ code as well, if you want to use it. I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support. "All those things will come. If you want them, wait for them." I don't agree - this is 'doing it wrong'. It's been out for years. This is way past 'early adoption'. 'Doing it right' means that it is easy for new and old developers. Right now - it's hard. Doing Swift 'right': 1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC. 2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'. 3) Beta for 1 year, then production. 4) No backwards-incompatible changes after out of beta. (Easier said than done). 5) Docs, examples etc that clearly demarcate versioning. 6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange. 7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff. 8) Free online courses, for newbs, and those coming from other languages, and Objc. They made Swift a little too complicated, and left devs hanging in the dark on so many issues.
    - fiedzia 10y ago
      > I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions? > It's been out for years. This is way past 'early adoption'. Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape. >Make Swift a clean break, get rid of some of the more obscure things that make it difficult. If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in. I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.

mpweiher 10y ago

>compatible with ObjC was one of the big issues Considering that was going to be hard requirement, maybe the problem was introducing so many things that are so incompatible with ObjC? There are tons of ways you could vastly improve the programming experience without introducing all this incompatible stuff.