10 ms·

Swift: Not quite there, but too far gone too

32 points by neop 12y ago

neop 12y ago
The article suffers from a bit from looking at things from a strictly theoretical knowledge (i.e. the first example is not valid Swift code), but it does bring up a few interesting points.
andrewflnr 12y ago
Optional types are not the only use of algebraic data types. I agree that it's weird to have them and optional operators in the same language, but I don't see it as a big issue.
lobster_johnson 12y ago
I agree that instances being pass-by-reference is weird, with everything else having copy semantics. It seems as yet another odd artifact of the design constraint that Swift must be ObjC-runtime compatible. I sort of wish they had created a special type annotation to support legacy ObjC classes, and gone for Go-style structs for the non-legacy OO.
- chc 12y ago
  It's more than that. I don't think having non-reference objects is entirely impossible (e.g. Objective-C blocks are already stack-based objects until they are copied), but it doesn't work for Swift's design goals. Objects have to be reference types because Swift needs to interact with Cocoa and Cocoa Touch, which assume reference-sharing in many places.
Kiro 12y ago
I don't understand the obsession with mutability. When is it a problem that a variable is mutable?
- mamcx 12y ago
  Probably because is hard to track the chain of calls that could have change the data. If inmutable, you are sure what exactly you have at hand. But the article point to a inconsistent mutable/inmutable behavior that is more problematic.
- perishabledave 12y ago
  Check out Rich Hickey's (the creator of Clojure) talk The Value of Values. He makes a good case for immutability. http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the-value-of-values http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the...
- netcraft 12y ago
  When it surprises you. It is easier to reason about code when you know that values will not change - an immutable value cannot change so you don't have to worry about passing it around, using it in asynchronous processes, changing it without persisting the change, etc.
- ozten 12y ago
  It is a very different way of thinking about programming, but immutable inputs remove a whole class of bugs that can happen. It is analogous to global variables. We know they are bad, because any other piece of code can change them and break our code. A variable having state is similar. When you think about what a function does or write tests... having the variable be able to have many unknown states increases the complexity. In code we write everyday, a variable might be undefined, null, a valid phone number as a string, etc. But in immutable code, if your input comes from a function that returns either None or a valid phone number as a string and no other code can tweak this... then your code becomes much easier to think about and write tests for.
- deleted 12y ago
  [deleted]
  - colanderman 12y ago
    Most modern compilers transform source code into a single-static assignment form, rendering (im)mutability notations useless from an optimization standpoint. (Ignoring for now the case of non-local assignment, e.g. through aliased pointers.) What you actually gain from (im)mutability notation is documentation and sanity checks: it's a huge win to tell the compiler "yell at me if I ever try to modify this variable", which unambiguously indicates to a human "don't worry, this variable is never modified in this code".
mamcx 12y ago
I start writing a ORM (that is how I learn a new language). Very fast I hit problems. The keynote and the state of union say swift is ready for production, but is not there yet. The coding experience is buggy, the repl violate the language (is possible to change a constant to another type!), the importing of other obj-c code is sometimes broken (ie: Not work at all, or yes). A lot of things are not documented (For example, how do a generator?), etc Still, I hope this lang mature and be popular, because I want badly to not use obj-c
- mamcx 12y ago
  Why the downvote?
  - albemuth 12y ago
    grammar maybe?
  - coldtea 12y ago
    Maybe because neither the keynote not the state of union said swift is ready for production.
    - mamcx 12y ago
      Do you see the videos? They expect to get apps made with swift on launch of iOS 8, and have rewrite at least the WWDC videos app as showcase. P.D: This remark was about 32 min in the state of union video
      - coldtea 12y ago
        The launch of iOS is several months in the future. Swift, as XCode 6, is still beta.
        mamcx 12y ago
        Yep, but in terms of languages, that is around the corner!
TwistedWeasel 12y ago
"... but this language, once released, will be fixed for a decade at least. Something with that lifespan should be great from day one." I'm not sure why the author believes that once the language ships it cannot change. Surely all languages evolve and change over time, it would be foolish to think Swift as it ships in September will not change for a decade after that.
- chc 12y ago
  A language that is constantly changing in fundamental ways is not usable for serious software. Languages are largely constrained by the choices that were made when they were released. See Python 3 for an example of what happens when a language tries to make breaking changes — and Python's were relatively minor! No language could thrive while going through that sort of strife constantly.
  - danudey 12y ago
    Objective-C has added several features in recent years; things like bindings, dot notation, etc. are relatively new, but pretty substantial changes in terms of code clarity. As for Python 3, the Python community never intended for people to move over to Python 3 immediately, nor was it intended for people to move their Python projects from Python 2 to Python 3 unless they had some reason to (e.g. Django, public libraries, etc).
    - chc 12y ago
      Objective-C has added things, but it has largely not changed existing things. As I said in another comment, languages generally do not change — they just accrete. If you feel like a language is missing something, that might be fixable — but if you feel like a language either added the wrong thing or did something the wrong way (which is the OP's concern), that is a much more difficult problem, because after release you can't take away what's already there without making people angry.
- wvenable 12y ago
  Languages generally don't change -- they get added-to and very rarely removed-from but they don't often change. For example, it's usually very hard to add new keywords. So C++ for example, uses every possible keyword and symbol overloaded to provide new features to the point of ridiculousness. Java is on the same road. Python changed a few things and the split between 2.x and 3.x is still ongoing.
AshFurrow 12y ago
> So this is a list of things I don’t like about Swift based on things I’ve read in the book, without having experimented with the language myself. I stopped reading about here.
- VeryVito 12y ago
  Yeah, this immediately made me picture Steve Carrell's character from "40-Year-Old Virgin" trying to describe what sex must be like.
josephlord 12y ago
> Except that you can still make changes that don’t affect length (immutArray[3] = "Whoopsie") That sounds like a bug to me. I would expect the compiler to detect it as an error (it doesn't). Can anyone point me to the relevant bit of the spec that says you can do that?
- cosn 12y ago
  "Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed." https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html#//apple_ref/doc/uid/TP40014097-CH8-XID_151 https://developer.apple.com/library/prerelease/ios/documenta...
  - josephlord 12y ago
    Thanks. I think it sounds like a bad decision, it can be compile time checked so won't cause performance issues. I wonder what the cost is in the mutable case for the fact that the length can vary.
  - danudey 12y ago
    So immutability is a code safety feature, except in the case of arrays, where it's a performance optimization. That seems counterintuitive.
sbuk 12y ago
FTFA; >"So this is a list of things I don’t like about Swift based on things I’ve read in the book, without having experimented with the language myself..." Question; why post this then?
- chc 12y ago
  Because one would hope that the official Swift book does a sufficient job of describing the language?
  - sbuk 12y ago
    Drop the snark. I doubt that it does a sufficient enough job to write a critique of a language that the OP admits they have they haven't tried! This article is nothing but here-say and as such is worthless.
    - chc 12y ago
      That wasn't snark; it was an answer. The fact that you have some unexplained "doubt" about whether it is correct does not make it snark. But let's delve in. Why is it impossible to analyze a language from a programming language theory perspective without having used it? Obviously having used it will give a fuller perspective, but I don't see what you think is so deficient about the extensive documentation Apple has put out that it's impossible to comment from a theoretical standpoint on that basis. To put it another way, I think you should drop the snark. If you have an actual problem with the critique or with the Swift documentation, you can bring it up. A snarky dismissal like "Question; why post this then?" does not add anything.
- ahomescu1 12y ago
  IMHO he made some valid points, all from reading the spec. Experimenting with the language wouldn't really invalidate them.
_random_ 12y ago
The good part is that the following smooth transition is now possible for the core iOS developers: ObjectiveC -> Swift -> C#: iOS, Android, Windows Phone etc.

32 points by neop 12y ago

neop 12y ago

The article suffers from a bit from looking at things from a strictly theoretical knowledge (i.e. the first example is not valid Swift code), but it does bring up a few interesting points.

andrewflnr 12y ago

Optional types are not the only use of algebraic data types. I agree that it's weird to have them and optional operators in the same language, but I don't see it as a big issue.

lobster_johnson 12y ago

I agree that instances being pass-by-reference is weird, with everything else having copy semantics. It seems as yet another odd artifact of the design constraint that Swift must be ObjC-runtime compatible. I sort of wish they had created a special type annotation to support legacy ObjC classes, and gone for Go-style structs for the non-legacy OO.

chc 12y ago
It's more than that. I don't think having non-reference objects is entirely impossible (e.g. Objective-C blocks are already stack-based objects until they are copied), but it doesn't work for Swift's design goals. Objects have to be reference types because Swift needs to interact with Cocoa and Cocoa Touch, which assume reference-sharing in many places.

Kiro 12y ago

I don't understand the obsession with mutability. When is it a problem that a variable is mutable?

mamcx 12y ago
Probably because is hard to track the chain of calls that could have change the data. If inmutable, you are sure what exactly you have at hand. But the article point to a inconsistent mutable/inmutable behavior that is more problematic.
perishabledave 12y ago
Check out Rich Hickey's (the creator of Clojure) talk The Value of Values. He makes a good case for immutability. http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the-value-of-values http://www.confreaks.com/videos/1830-jaxconf2012-keynote-the...
netcraft 12y ago
When it surprises you. It is easier to reason about code when you know that values will not change - an immutable value cannot change so you don't have to worry about passing it around, using it in asynchronous processes, changing it without persisting the change, etc.
ozten 12y ago
It is a very different way of thinking about programming, but immutable inputs remove a whole class of bugs that can happen. It is analogous to global variables. We know they are bad, because any other piece of code can change them and break our code. A variable having state is similar. When you think about what a function does or write tests... having the variable be able to have many unknown states increases the complexity. In code we write everyday, a variable might be undefined, null, a valid phone number as a string, etc. But in immutable code, if your input comes from a function that returns either None or a valid phone number as a string and no other code can tweak this... then your code becomes much easier to think about and write tests for.
deleted 12y ago
[deleted]
- colanderman 12y ago
  Most modern compilers transform source code into a single-static assignment form, rendering (im)mutability notations useless from an optimization standpoint. (Ignoring for now the case of non-local assignment, e.g. through aliased pointers.) What you actually gain from (im)mutability notation is documentation and sanity checks: it's a huge win to tell the compiler "yell at me if I ever try to modify this variable", which unambiguously indicates to a human "don't worry, this variable is never modified in this code".

mamcx 12y ago

I start writing a ORM (that is how I learn a new language). Very fast I hit problems. The keynote and the state of union say swift is ready for production, but is not there yet. The coding experience is buggy, the repl violate the language (is possible to change a constant to another type!), the importing of other obj-c code is sometimes broken (ie: Not work at all, or yes). A lot of things are not documented (For example, how do a generator?), etc Still, I hope this lang mature and be popular, because I want badly to not use obj-c

mamcx 12y ago
Why the downvote?
- albemuth 12y ago
  grammar maybe?
- coldtea 12y ago
  Maybe because neither the keynote not the state of union said swift is ready for production.
  - mamcx 12y ago
    Do you see the videos? They expect to get apps made with swift on launch of iOS 8, and have rewrite at least the WWDC videos app as showcase. P.D: This remark was about 32 min in the state of union video
    - coldtea 12y ago
      The launch of iOS is several months in the future. Swift, as XCode 6, is still beta.
      - mamcx 12y ago
        Yep, but in terms of languages, that is around the corner!

TwistedWeasel 12y ago

"... but this language, once released, will be fixed for a decade at least. Something with that lifespan should be great from day one." I'm not sure why the author believes that once the language ships it cannot change. Surely all languages evolve and change over time, it would be foolish to think Swift as it ships in September will not change for a decade after that.

chc 12y ago
A language that is constantly changing in fundamental ways is not usable for serious software. Languages are largely constrained by the choices that were made when they were released. See Python 3 for an example of what happens when a language tries to make breaking changes — and Python's were relatively minor! No language could thrive while going through that sort of strife constantly.
- danudey 12y ago
  Objective-C has added several features in recent years; things like bindings, dot notation, etc. are relatively new, but pretty substantial changes in terms of code clarity. As for Python 3, the Python community never intended for people to move over to Python 3 immediately, nor was it intended for people to move their Python projects from Python 2 to Python 3 unless they had some reason to (e.g. Django, public libraries, etc).
  - chc 12y ago
    Objective-C has added things, but it has largely not changed existing things. As I said in another comment, languages generally do not change — they just accrete. If you feel like a language is missing something, that might be fixable — but if you feel like a language either added the wrong thing or did something the wrong way (which is the OP's concern), that is a much more difficult problem, because after release you can't take away what's already there without making people angry.
wvenable 12y ago
Languages generally don't change -- they get added-to and very rarely removed-from but they don't often change. For example, it's usually very hard to add new keywords. So C++ for example, uses every possible keyword and symbol overloaded to provide new features to the point of ridiculousness. Java is on the same road. Python changed a few things and the split between 2.x and 3.x is still ongoing.

AshFurrow 12y ago

> So this is a list of things I don’t like about Swift based on things I’ve read in the book, without having experimented with the language myself. I stopped reading about here.

VeryVito 12y ago
Yeah, this immediately made me picture Steve Carrell's character from "40-Year-Old Virgin" trying to describe what sex must be like.

josephlord 12y ago

> Except that you can still make changes that don’t affect length (immutArray[3] = "Whoopsie") That sounds like a bug to me. I would expect the compiler to detect it as an error (it doesn't). Can anyone point me to the relevant bit of the spec that says you can do that?

cosn 12y ago
"Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed." https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html#//apple_ref/doc/uid/TP40014097-CH8-XID_151 https://developer.apple.com/library/prerelease/ios/documenta...
- josephlord 12y ago
  Thanks. I think it sounds like a bad decision, it can be compile time checked so won't cause performance issues. I wonder what the cost is in the mutable case for the fact that the length can vary.
- danudey 12y ago
  So immutability is a code safety feature, except in the case of arrays, where it's a performance optimization. That seems counterintuitive.

sbuk 12y ago

FTFA; >"So this is a list of things I don’t like about Swift based on things I’ve read in the book, without having experimented with the language myself..." Question; why post this then?

chc 12y ago
Because one would hope that the official Swift book does a sufficient job of describing the language?
- sbuk 12y ago
  Drop the snark. I doubt that it does a sufficient enough job to write a critique of a language that the OP admits they have they haven't tried! This article is nothing but here-say and as such is worthless.
  - chc 12y ago
    That wasn't snark; it was an answer. The fact that you have some unexplained "doubt" about whether it is correct does not make it snark. But let's delve in. Why is it impossible to analyze a language from a programming language theory perspective without having used it? Obviously having used it will give a fuller perspective, but I don't see what you think is so deficient about the extensive documentation Apple has put out that it's impossible to comment from a theoretical standpoint on that basis. To put it another way, I think you should drop the snark. If you have an actual problem with the critique or with the Swift documentation, you can bring it up. A snarky dismissal like "Question; why post this then?" does not add anything.
ahomescu1 12y ago
IMHO he made some valid points, all from reading the spec. Experimenting with the language wouldn't really invalidate them.

_random_ 12y ago

The good part is that the following smooth transition is now possible for the core iOS developers: ObjectiveC -> Swift -> C#: iOS, Android, Windows Phone etc.