Re: swift and objective-c
Re: swift and objective-c
- Subject: Re: swift and objective-c
- From: Ron Hunsinger <email@hidden>
- Date: Tue, 03 Jun 2014 14:16:41 -0700
On Jun 3, 2014, at 6:17 AM, Roland King <email@hidden> wrote:
> I'm chewing through the Swift book trying to keep an open mind. My first though was "what, another language" and my second thought was "what, another language" and my third thought was I should get to the end of the book before deciding some of the syntax is decidedly odd. If you haven't looked, look, I haven't quite discerned the pattern in the language yet but I'm only on page 65. There's a few PERL'y bits in there, as in you can write it like this, or that, or shorter, or you can replace all the variables with ! _ $ # & and ^, put it in curly braces outside the function call and it will still work somehow. Sorry .. open mind, open mind.
I'm also chewing through the manual, trying to keep an open mind. My initial reaction is mostly positive, but there are some defects:
The range operators:
- In Swift, a..b includes a and excludes b; a...b includes both endpoints.
- In Ruby, it's exactly the opposite. a..b includes both endpoints; a...b excludes b.
- In Pascal, a..b includes both endpoints. There is no ... operator.
Quotient/remainder:
- In Swift, a % b ignores the sign of b. A non-zero remainder has the same sign as a.
- Ruby does it right; A non-zero remainder has the same sign as the divisor.
Anyone who has ever tried to implement Number Theory algorithms will have learned that letting the sign of the remainder depend on the sign of the dividend means that you have to add a whole lot of defensive code around all your modular arithmetic. The expression 'x % 10' should return a value in the range 0 thru 9, regardless of the sign of x. (Think about computing which of 10 buckets to put an item in. "Number Theory" need not be exotic.) Absent that guarantee, you have to write ((x % 10) + 10) % 10, or use a conditional branch and introduce pipeline stalls. And if x % 16 is to have the sign of x, the compiler cannot optimize it to (x & 15).
Historically, the IBM 704/709 computers did quotient/remainder wrong. Therefore, Fortran did it wrong. Therefore every later processor that wanted to "support Fortran" needed to do it wrong. Therefore the C standardizers caved, and said "the compiler should do it the way the hardware does", meaning in practice that C always does it wrong too. (Which, I guess, is why Swift does it wrong. When they threw out C, they didn't throw away enough.)
The quotient/remainder thing I suppose I can live with. It's not like I haven't had to live with it before.
Flipping the meaning of the .. and ... operators is the more troublesome. I already have enough trouble keeping Ruby and Python straight. They're similar enough to get blurred together in my head, but the details are so different. (To take absolute value, is it x.abs or abs(x)? That is, is "abs" a function or a method? Same meaning, different semantics and therefore different syntax. Do you "include" or "require" or "import" or "use" libraries? Same words, different meanings. Is it "elif" or "elsif" or "else if"? Same meaning, different words.) Now throw in Swift, which is just enough like Ruby, Python AND Perl to foster hard-to-spot bugs.
I like learning new languages, but it's easier when they're actually new. "Familiar" lets you speed-read the manual the first time through, but then you're constantly going back to the manual to get the niggling little details straight.
But, I'll keep an open mind for now. Swift seems, so far, no worse than C in any feature, and better in some.
-Ron Hunsinger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden