Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›2 »

Toady: Jan 12, 2009

lord funk posted:

Toady could you give some examples of how this will make things better? I'm willing to admit that maybe the examples so far have been weak, so if there's some good stuff I'm missing, I'd love to see it.

If you don't agree with Apple's proposal, I doubt my opinions would be persuasive. Objective-C's verbose style has its roots in an era when all objects were id and methods returned self by default. Restating the types enforced by the Swift compiler feels anachronistic. In imagining these APIs as if they been written for Swift instead of imported from Objective-C, it's hard to picture them being as verbose as they are now. Note that exceptions are made for potentially vague call sites.

The argument has a subjective element; the proposal's examples feel more "Swift-like" to me. However, there have been calls for a more concise API for a long time. John Siracusa once singled out -componentsSeparatedByString: and compared it to what's more commonly known as split() in other languages. To use an example from the proposal:

code:

let content = listItemView.text.stringByTrimmingCharactersInSet(
    NSCharacterSet.whitespaceAndNewlineCharacterSet())
let content = listItemView.text.trimming(.whitespaceAndNewlines)

To me, no clarity is lost in the second form, and it's more readable. From a pedagogical perspective, the shorter form is less intimidating, easier to present, and simpler to read and write.

I'm also biased by accessibility needs. I experience visual snow and ghosting, and big chunks of verbose Cocoa code are irritating to read through, especially after working in concise languages with more whitespace.

# ¿ Feb 1, 2016 00:48

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 14:29

Toady: Jan 12, 2009

Doctor w-rw-rw- posted:

Having taught programming before, the idea that the greater character count is more intimidating is absolutely preposterous.

As a newcomer, I found Cocoa imposing and difficult to absorb.

squidgee posted:

For example, let's say I can't remember some particular method name. This happens to me all the time. I know that what I want exists, but I don't remember exactly what it's called. So how do I find the method name? 90% of the time, I use autocomplete to guess it on the first or second try. For instance, I know that the method for combining two strings is probably something like, "stringByCombiningWithAnotherString:," so I can punch in "stringBy" and stringByAppendingString: pops up. If stringByAppendingString: were renamed something terse like append:, I'd have to resort to the documentation to find it.

It's even more terse than that: string1 + string2

# ¿ Feb 3, 2016 02:45

Toady: Jan 12, 2009

I didn't mean to call you out. Your examples use Objective-C syntax, so I didn't know if you had used Swift.

# ¿ Feb 3, 2016 03:16

Toady: Jan 12, 2009

Kallikrates posted:

Is the clarity team an actual team in the Swift project? If he sees it as an Us(me) vs them thing maybe that's why he can sit on those threads all day.

Dave Abrahams works at Apple as a language designer and technical lead on the standard library. He's a co-author of the proposal, so naturally he's heavily involved in the discussions. I'm not sure what is meant by "us vs. them thing," though. He was addressing each point raised like one would expect on a mailing list devoted to language design.

I think some of you have the wrong impression. It's not about brevity versus clarity. What's being removed are redundant words that don't add clarity to the semantics. For example, addSubview(_:) is unchanged.

# ¿ Feb 4, 2016 02:09

Toady: Jan 12, 2009

"Team brevity" is just a snarky term someone used in the discussion.

# ¿ Feb 4, 2016 02:24

Toady: Jan 12, 2009

I've never had the impression that the Swift team was opposed to dynamism. They just haven't finished designing Swift's answers to those problems that demand dynamism.

# ¿ May 24, 2016 18:18

Toady: Jan 12, 2009

John Gruber seemed interested in linking every article he could find this week. Wil Shipley is treating it as an overreaction.

# ¿ May 28, 2016 03:32

Toady: Jan 12, 2009

I thought default public non-subclassability was sensible, but apparently bureaucratic forces are just restricting my freedom without reason or purpose. I'm grateful that people on the mailing list have opened my eyes.

# ¿ Jul 20, 2016 18:02

Toady: Jan 12, 2009

ultramiraculous posted:

This explanation is one I've heard brought up in conversation before and it would make a ton of sense. It seems like there's a decent number of community members who are using the project as a vanity-contribution opportunity where they can argue about aesthetics, despite not really using the language.

It's a vocal minority with absurd ways of expressing themselves. They're psychoanalyzing the Swift team as "bureaucrat" personalities and themselves as "hacker" personalities. One of them compared himself to Steve Jobs. We're supposed to feel bad when they inform the mailing list that they're rejecting Swift.

It reminds me of some of the weirdness that used to get posted to the Objective-C mailing list after changes like ARC.

Toady fucked around with this message at 23:15 on Jul 21, 2016

# ¿ Jul 21, 2016 23:12

Toady: Jan 12, 2009

If people want to follow the mailing lists without using a mail client or being able to post to discussions, Hirundo is a free Swift mailing list archive browser.

Edit: Actually, if you're subscribed to a list, it will open Mail to compose a reply.

Toady fucked around with this message at 23:05 on Aug 1, 2016

# ¿ Aug 1, 2016 16:01

Toady: Jan 12, 2009

It's convenient for browsing older posts, but I find it simpler to follow the mailing lists via a mail client.

# ¿ Aug 2, 2016 17:02

Toady: Jan 12, 2009

dc3k posted:

Ah, all of my cases do return, so the fact that it's saying its unreachable I don't have a problem with. It makes sense. But the fact that it's saying it's not exhaustive when I've covered the entire enum is what's confusing.
code:
 switch type {
 case .CaseA(_, let b?, _):
   return something
 case .CaseB(_, let b?):
   return something
 case .CaseC(_, let b?):
   return something
 }
and the enum definition:
code:
 enum Type {
  case CaseA(a: String?, b: Foo?, c: Bar?)
  case CaseB(a: String?, b: Baz?)
  case CaseC(a: String?, b: FooBar?)
}

You're checking for cases of non-nil b with let b?, so you also need to cover cases of nil b.

# ¿ Sep 28, 2016 19:35

Toady: Jan 12, 2009

dc3k posted:

I guess I just have no idea how these fancy enums with parameters work

It might clarify to remember that optionals are really enums that are either .some(T) or .none. Writing let b? in the case statement is equivalent to writing .some(let b). Therefore, to be exhaustive, you also have to handle the .none case.

# ¿ Sep 28, 2016 22:21

Toady: Jan 12, 2009

There's a thread on the mailing list where people are advocating reverting SE-0025 and insisting that there's "near unanimous agreement" that we should go back to Swift 2's behavior. I've been happily using private/fileprivate since Swift 3 came out, so maybe I'm out of the loop. What's wrong with it?

# ¿ Feb 18, 2017 19:55

Toady: Jan 12, 2009

The argument of a slippery slope toward finer gradations is a fair point. I was confused by the thread's claims that it's "actively harmful" and adds "cognitive load." I haven't felt confused or even really thought much about it beyond occasionally changing a private to fileprivate to share something.

# ¿ Feb 19, 2017 19:05

Toady: Jan 12, 2009

Flobbster posted:

The obvious right thing to do is admit that SE-0025 was a bad idea and roll it back. Nobody needs scoped access vs. file-private access�you're only protecting yourself from yourself. It's a pointless distinction and if you need it, your files are too drat big.

That came up in the thread amongst all the hyperbole and noise. "Big" is subjective, and sometimes you're not working on files you wrote. The most reasonable suggestion to me was to make the compiler warn about unnecessary uses of fileprivate to better match the intent of the original proposal and allow the team to gauge legitimate usage. But I'm coming from the position of having never had an issue with private/fileprivate.

Simulated posted:

Fortunately we have an easy out without breaking source compatibility; revert private to its old behavior and make fileprivate a synonym.

Wouldn't this break?

code:

class ContrivedExample {
    private func foo() {}
}

extension ContrivedExample {
    private func foo() {}
}

Toady fucked around with this message at 19:32 on Feb 21, 2017

# ¿ Feb 21, 2017 19:15

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 14:29

Toady: Jan 12, 2009

Flobbster posted:

If somebody does something that dumb, they deserve to be broken

I can picture someone reusing a name (accidentally or otherwise) because the previous declaration was a hidden detail they didn't know they would need to consider in the event that private's behavior was reverted.

Toady fucked around with this message at 21:54 on Feb 21, 2017

# ¿ Feb 21, 2017 20:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›2 »