Swift: Not quite there, but too far gone too • Hacker News Board

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

#11

Post by TwistedWeasel » Wed, Jun 04, 2014, 6:43 PM UTC

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

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

#12

Post by netcraft » Wed, Jun 04, 2014, 6:44 PM UTC

Kiro wrote: post #6

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

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.

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

#13

Post by chc » Wed, Jun 04, 2014, 6:46 PM UTC

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.

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

#14

Post by ozten » Wed, Jun 04, 2014, 6:48 PM UTC

Kiro wrote: post #6

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

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.

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

#15

Post by [deleted] » Wed, Jun 04, 2014, 6:48 PM UTC

Kiro wrote: post #6

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

[deleted]

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

#16

Post by albemuth » Wed, Jun 04, 2014, 6:50 PM UTC

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?

grammar maybe?

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

#17

Post by wvenable » Wed, Jun 04, 2014, 6:52 PM UTC

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.

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.

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

#18

Post by coldtea » Wed, Jun 04, 2014, 6:54 PM UTC

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?

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

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

#19

Post by AshFurrow » Wed, Jun 04, 2014, 6:55 PM UTC

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

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

#20

Post by stormbrew » Wed, Jun 04, 2014, 6:55 PM UTC

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 expectation seems like it's probably based on real history, but things seem different now, though. Languages are evolving faster than before, even some of the ones that previously moved very slowly.