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

41–50 of 50 posts

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

#41

Post by danudey »

chc wrote: post #13
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.

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.

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

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

#42

Post by danudey »

stormbrew wrote: post #30
chc wrote: post #27

Earlier quoted context omitted.

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…

Python 3 is also not meant to run Python 2.x code. It's pretty trivial to port most code from Python 2.x to Python 3, but there's no real reason to do so unless you're writing a library or other project for other people to take advantage of.

It was intentionally done as a 'clean break' release; 2.x keeps doing the same stuff it used to do, and Python 3 changes a bunch of stuff which, in hindsight, makes sense (such as a distinction between 'stream of bytes' and 'string of text', vs. 'stream of bytes which may or may not be ascii text' and 'string of unicode text').

That said, there's no real benefit to moving an existing project/codebase from 2.x to 3.x, and it was never intended that there would be one. Python 3 is for new projects; Python 2.x is for existing projects, or new projects which need deployment in older environments.

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

#43

Post by danudey »

cosn wrote: post #29
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/prerele…

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

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

#44

Post by chc »

danudey wrote: post #41
chc wrote: post #13

Earlier quoted context omitted.

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.

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

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.

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

#45

Post by stormbrew »

danudey wrote: post #42
stormbrew wrote: post #30

Earlier quoted context omitted.

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…

Python 3 is also not meant to run Python 2.x code. It's pretty trivial to port most code from Python 2.x to Python 3, but there's no real reason to do so unless you're writing a library or other project for other people to take advantage of. It was intentionally done as a 'clean break' release; 2.x keeps doing the same stuff it used to do, and Python 3 changes a bunch of stuff which, in hindsight, makes sense (such a…

Which is one of the reasons I think it's a sign towards acceleration. People are developing strategies to deal with language evolution. This, "import from __future__", and gofmt are all tooling that helps you deal with a language that's still willing to evolve.

That said, I don't think this part of the python3 effort entirely succeeded. Unfortunately they share a package source, so a lot of projects do need to support both. But whatever failings there have been in the python jump to 3.0, they're nothing compared to the disaster that was ruby 1.9, even though I think 1.8.7 is truly relegated to legacy now.

As long as they learn from those issues, though, I think the future is bright for non-stagnating languages.

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

#46

Post by josephlord »

cosn wrote: post #29
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/prerele…

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.

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

#47

Post by VeryVito »

AshFurrow wrote: post #19

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

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

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

#48

Post by coldtea »

mamcx wrote: post #31
coldtea wrote: post #18

Earlier quoted context omitted.

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

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

The launch of iOS is several months in the future.

Swift, as XCode 6, is still beta.

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

#49

Post by mamcx »

coldtea wrote: post #48
mamcx wrote: post #31

Earlier quoted context omitted.

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

The launch of iOS is several months in the future. Swift, as XCode 6, is still beta.

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

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

#50

Post by samth »

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…

This isn't right about the renaming. The switch from mutable pairs to immutable pairs happened in release 4.0 of PLT Scheme, in June 2008. The name change was in May 2010.
Post reply on HN