

Swift: Not quite there, but too far gone too - neop
http://studentf.wordpress.com/2014/06/03/swift-not-quite-there-but-too-far-gone-too/

======
mamcx
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
Why the downvote?

~~~
coldtea
Maybe because neither the keynote not the state of union said swift is ready
for production.

~~~
mamcx
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
The launch of iOS is several months in the future.

Swift, as XCode 6, is still beta.

~~~
mamcx
Yep, but in terms of languages, that is around the corner!

------
neop
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.

------
lobster_johnson
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
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.

------
josephlord
> 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
"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/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html#//apple_ref/doc/uid/TP40014097-CH8-XID_151)

~~~
danudey
So immutability is a code safety feature, except in the case of arrays, where
it's a performance optimization. That seems counterintuitive.

------
andrewflnr
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.

------
TwistedWeasel
"... 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
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
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
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.

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

~~~
ozten
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.

------
AshFurrow
> 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
Yeah, this immediately made me picture Steve Carrell's character from
"40-Year-Old Virgin" trying to describe what sex must be like.

------
_random_
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.

------
sbuk
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
Because one would hope that the official Swift book does a sufficient job of
describing the language?

~~~
sbuk
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
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.

