Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift: Not quite there, but too far gone too

studentf.wordpress.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Swift: Not quite there, but too far gone too

#21

Post by sanderjd »

mamcx wrote: post #10
mamcx wrote: post #7

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 ex…

Why the downvote?

No idea why someone would have downvoted you. Your post was the first one that has given me insight into what it's actually like to work with the language at this early stage.

Re: Swift: Not quite there, but too far gone too

#22

Post by colanderman »

[deleted] wrote: post #15
Kiro wrote: post #6

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

[deleted]

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

Re: Swift: Not quite there, but too far gone too

#23

Post by 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?

Re: Swift: Not quite there, but too far gone too

#25

Post by chc »

sbuk wrote: post #24

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?

Because one would hope that the official Swift book does a sufficient job of describing the language?

Re: Swift: Not quite there, but too far gone too

#27

Post by chc »

stormbrew wrote: post #20
TwistedWeasel wrote: post #11

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

This was about the pace of language development once upon a time. C++ changed glacially for its first 20 years, for example. Perl, Ruby, and Python also took pretty conservative approaches to language evolution (but kudos to Python for finding a way to encode versioning information into the code itself). I think Objective-C didn't really change all that much until the mid-2000s, probably in prep for iOS? So the expec…

By and large, languages don't really change — they just accrete. It is very rare for something that used to work one way to later work another way. For example, languages generally do not go from being statement-based to being expression-based, or go from something being mutable to immutable, or eliminate operators. (MzScheme did the second one — it went from mutable to immutable defaults — and it was considered so significant that they stopped calling their language Scheme and renamed it Racket to avoid confusion!)

Re: Swift: Not quite there, but too far gone too

#28

Post by r00fus »

mamcx wrote: post #7

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 ex…

Can you provide more details? All of the issues you mention seem like typical early beta expectations.

Re: Swift: Not quite there, but too far gone too

#29

Post by cosn »

josephlord wrote: post #23

> 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?

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

Re: Swift: Not quite there, but too far gone too

#30

Post by stormbrew »

chc wrote: post #27
stormbrew wrote: post #20

Earlier quoted context omitted.

This was about the pace of language development once upon a time. C++ changed glacially for its first 20 years, for example. Perl, Ruby, and Python also took pretty conservative approaches to language evolution (but kudos to Python for finding a way to encode versioning information into the code itself). I think Objective-C didn't really change all that much until the mid-2000s, probably in prep for iOS? So the expec…

By and large, languages don't really change — they just accrete. It is very rare for something that used to work one way to later work another way. For example, languages generally do not go from being statement-based to being expression-based, or go from something being mutable to immutable, or eliminate operators. (MzScheme did the second one — it went from mutable to immutable defaults — and it was considered so s…

I agree this has historically been true, but again, I think this is changing. Ruby 1.9 and Python 3 both did more than accrete, they actively broke existing code in quite significant ways.

C++ has so far avoided completely breaking changes, but with all the accretion it's doing now it's probably only a matter of time before some significant breaking changes happen lest it become even more ridiculously complex than it is now.

Go has had breaking changes as well, I believe, but they have a smart upgrade tool to help with it. This is probably something that will catch on for other rapidly evolving languages.

I think we'll see a lot more of this kind of thing in the future.

Post reply on HN