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

«‹›3 »

Doctor w-rw-rw-: Jun 24, 2008

Axiem posted:

Speaking of, when is Swift going to be open-sourced, again? I could have sworn it was sometime soon.

According to the swift subreddit still on track to EOY 2015

# ¿ Dec 1, 2015 17:36

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 18:06

Doctor w-rw-rw-: Jun 24, 2008

#calledit (sorta?)

# ¿ Dec 3, 2015 17:16

Doctor w-rw-rw-: Jun 24, 2008

Developed under Apple's banner, with their name taking the reputation hit it if sucks rear end (it won't) is good enough for me, I think, because a) it aligns their incentives with making it not crap, b) it'll be consistent across platforms to the degree it can be, and c) they have the technical resources on hand to refer to with regards to issues with the original Foundation implementation. And it means also that maybe they'll adopt Swift's Foundation over time � maybe.

Also, a commitment to make libdispatch a better option on non-Darwin platforms is very, very welcome news. Now Linux people can (officially) see the light of GCD*!

* yeah, yeah, it wasn't impossible before, with libpthread-workqueue, but again, official support is awesome

# ¿ Dec 3, 2015 17:27

Doctor w-rw-rw-: Jun 24, 2008

Now I'll have to satisfy my neckbeard impulse to demand virtually impossible things by complaining that Core Data isn't open-source!

No but seriously, I am seriously stoked to see/use/program Swift on the backend.

# ¿ Dec 3, 2015 17:32

Doctor w-rw-rw-: Jun 24, 2008

I have to update to 10.11 to get the latest, hopefully-non-segfaulting version of the Swift compiler?

*whines*

# ¿ Jan 30, 2016 01:58

Doctor w-rw-rw-: Jun 24, 2008

https://swift.org/blog/swift-api-transformation/ posted:

Swift code:

class UIBezierPath : NSObject, NSCopying, NSCoding { ... }
...
path.addLineToPoint(CGPoint(x: 100, y: 0))
path.fillWithBlendMode(kCGBlendModeMultiply, alpha: 0.7)

and after:

Swift code:

class UIBezierPath : Object, Copying, Coding { ... }
...
path.addLineTo(CGPoint(x: 100, y: 0))
path.fillWith(kCGBlendModeMultiply, alpha: 0.7)

Good lord, this is awful. Is addLine(toPoint:) not clearly better than deleting the context outright?

rjmccall, please find whoever thought the 'after' is an improvement and slap them (not a serious suggestion). I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that."

# ¿ Jan 30, 2016 19:24

Doctor w-rw-rw-: Jun 24, 2008

So, separate question - what's the best way for me to do SSL in a cross-platform way? I'm writing async network stuff using GCD dispatch sources + sockets directly, and I want to layer SSL atop it.

GnuTLS? NSS? I know Secure Transport and Common Crypto are open-source, but I don't know whether they've gotten Swifty, so to speak. Are they candidates for either inclusion with or porting to Swift, or would export restrictions restrain that?

# ¿ Jan 30, 2016 21:18

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them.

Basically, there are things I dislike about the Great Renaming, ~~but~~ and dropping ~~generic, redundant~~ clear, readable labels like ~~"object"~~ "withObject:" and ~~"point"~~ "toPoint" ~~isn't really~~ is definitely one of them.

rjmccall posted:

As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things.

I hate when people (read: HN users) pile on to (for example) GitHub issues and offer comments without committing to a discussion and end up adding noise instead of useful commentary, so I'm not really willing to participate directly since I'd prefer to be writing code or ~~poo poo~~posting/discussing here instead of ignoring/forgetting to participate elsewhere. FWIW, I'm fine with my post being excerpted or reposted elsewhere, if it's actually worth sharing.

For me, it's less about restating the types and more about losing the preposition. Take -convertPoint:toLayer:, -convertPoint:fromLayer, and -convertRect:toLayer:, for example. Sure, you could overload it so you have convert(_:, to:) and convert(_:, from:), but now you're not just removing redundancy, you're killing vital context. Using let allows you to not have to restate obvious type information, but let a = someThingThatReturnsACGPoint followed by convert(a, someLayer) is now stupidly ambiguous. convert(a, to:someLayer) is less stupidly ambiguous, but it's still ambiguous, because now there's no hint (my obtuse naming aside) that it's converting a point and not a rect.

So, again, two parts make it suck: a) apparent loss of useful prepositions, and b) loss of any hint because 'let'/'var' eliminates most of the actual bad redundancy. The method names are good redundancy because they're there for context-independent readability.

EDIT: and I may also be missing the point that prepositions wouldn't be removed, simply moved outside to the method name rather than being left in the parameter. I don't like this because for one thing, moving it to the method name can only really accommodate a single parameter name, and second, I value that the method names with different parameters create a much more natural grouping of similar methods. I can see the obvious counterargument, though.

Doctor w-rw-rw- fucked around with this message at 23:25 on Jan 30, 2016

# ¿ Jan 30, 2016 23:21

Doctor w-rw-rw-: Jun 24, 2008

Gul Banana posted:

cocoa's explicit method names were useful in a more dynamic language and time, where messaging was rarely or barely type-checked. if xcode's completion and overlays for swift have finally stabilised, the types in the function signatures will be a better guide than verbose naming ever was, and the names become redundant.

this is kind of an extreme version of the anti-comment argument - names shouldn't repeat or attempt to informally specify information which can be *verifiably* encoded as types.

Until clang can feed my eyes and brain type metadata directly, I'l take the redundancy, because it's information I'd otherwise have to expend effort to view anyhow, which gets in the way of scanning a great deal of code very quickly and intuitively discriminating between similar methods when debugging code.

:colbert:

Losing the visual information takes away a tangible part of Swift's appeal to me, because it's just making it hard for me to quickly correlate things.

# ¿ Jan 30, 2016 23:43

Doctor w-rw-rw-: Jun 24, 2008

While on the topic of Swift language features, what is your opinion on language support for inline composition of object hierarchies?

Specifically, I mean JSX-like syntax, but without necessarily implying support for XML � perhaps just something that would make a library to implement a DSL like that possible. Easy inline composition of object hierarchies is very useful for inline markup of UI components / views. Android's UI format is literally XML, but not inline whereas React's is a simple XML-like syntax.

(I ask because Swift doesn't strike me as the kind of language where third party support for it would be particularly tractable, whereas an interpreted language with sourcemaps like JS does.)

# ¿ Jan 31, 2016 08:04

Doctor w-rw-rw-: Jun 24, 2008

Like I already said, cmd-clicking doesn't mean much to me when I'm scanning a lot of code. This is shaving redundancy for redundancy's sake, and for the same amount of clarity forces the developer to write better variable names. Which doesn't scale to situations when you're reading someone else's lovely code.

Forcing the developer to choose between an inline constructor or well-named variables means that the language is now constrained at an API level to disallow implicit conversions at any point in the future lest the deleted context cause usage of an API to ambiguous or otherwise very opaque to the developer when debugging.

To make this concrete, for example, let's say syntax like "addLineTo((100,100))" were under consideration. Now let's say there were two methods, addLineToPoint: and addLineToSize:. "addLineTo((100,100))" would be ambiguous, whereas "addLine(toPoint:(100,100))" and "addLine(toSize:(100,100))" wouldn't, and what's more, would clearly distinguish between the different methods. So, of course, this would constrain the language because two previously different methods would now appear as overloads.

So, something with -[B fooWithNumber:(int32_t)], -[A fooWithString:(NSString *)], and -[A fooWithAny:(id)] might get translated as::

Swift code:

class A {
    func foo(any: AnyObject) -> String {
        return "A.foo - any: \(any)"
    }

    func foo(string: String) -> String {
        return "A.foo - string: \(string)"
    }
}

class B: A {
    func foo(number: Int32) -> String {
        return "B.foo - Int32: \(number)"
    }
}

A().foo(A())
A().foo("asdf")
B().foo("qwer")
B().foo(1)
B().foo(Int32(1))

outputs

code:

"A.foo - any: A"
"A.foo - string: asdf"
"A.foo - string: qwer"
"A.foo - any: 1"
"B.foo - Int32: 1"

Which is dumb, because now that you lack the name as context, you're boned and have to add redundancy back again anyways ("Int32(1)"), only now it's uglier and more prone to error.

Unless I've made a mistake in my reasoning, which is totally possible, I think this would be an annoying change that introduced annoying bugs. It's nonsense. It gives little and takes a lot away.

# ¿ Jan 31, 2016 19:23

Doctor w-rw-rw-: Jun 24, 2008

Toady posted:

I don't understand what you mean with the tuple-based addLineTo((100,100)) example, since my understanding is that the translation will be like this:

I'm saying it removes the possibility of other changes in the language, i.e. if it can deduce the type of the argument, it could elide the redundant type name. It was a what-if example to illustrate a tradeoff.

Toady posted:

But your example is deliberately using the non-descriptive method name foo, so of course it's confusing. I'm fine with edge cases like Int32(1) standing out with an initializer since explicitly sized integers are rare/discouraged in Swift, and you'd already have to explicitly specify the type when initializing such a variable or constant with a literal value.

The method name was built to not distract from the problem, which was that it makes stupidly ambiguous situations far easier to create. Take the previous example and replace class A's definition with

code:

class A {
    func foo(string: String) -> String {
        return "A.foo - string: \(string)"
    }
}

extension A {
    func foo(any: AnyObject) -> String {
        return "A.foo - any: \(any)"
    }
}

Now the method resolves differently, even though class A's interface barely changed; it just got shuffled. Simply because there's no word as context, an entirely different code path was taken in a way that is really easy for a developer to miss unless they really understand the system.

Hell, yesterday I had to step in after a pair of people writing Python struggled to realize that keyword args must come after positional args for 15-30 minutes. If they can get tripped up by something that simple in a language like Python, when they run into stuff like this? Yeah...

Programmers will *definitely* run into it and waste time, and it's not only avoidable it's currently avoided.

# ¿ Jan 31, 2016 20:49

Doctor w-rw-rw-: Jun 24, 2008

You're focusing on the wrong thing. It doesn't require AnyObject.

Swift code:

class SuperType { }

class SubType : SuperType { }


class A { }
extension A {
    func foo(superType: SuperType) -> String {
        return "A.foo(SuperType): \(superType)"
    }
}

class B: A {
    func foo(subType: SubType) -> String { // Not an override
        return "B.foo(SubType): \(subType)"
    }
}

A().foo(SuperType())
B().foo(SubType()) // still works if B.foo is deleted, easily avoidable with names
                   // (assuming the methods are meant to do something different)
B().foo(SubType() as SuperType) // Different method called, equivalent to...
B().foo(SuperType())
A().foo(SubType())

outputs

code:

A.foo(SuperType): SuperType
B.foo(SubType): SubType
A.foo(SuperType): SubType
A.foo(SuperType): SuperType
A.foo(SuperType): SubType

"A reasonably-designed API" is incredibly optimistic. This opens a big fat :can:

, and shortening the API methods makes it incredibly easy to screw things up. I'm writing code that already compiles, and managing to shoot myself in the foot. Now imagine giving sidearms to every single bridged API and saying "as long as you don't point this at your foot, you'll be fine". It's going to result in way more bleeding feet than necessary.

It barely matters that the examples are slightly contrived, IMO, because it's still not a hard problem to stumble across, and trivially avoidable at that.

EDIT: line break in comment in code

Doctor w-rw-rw- fucked around with this message at 21:28 on Jan 31, 2016

# ¿ Jan 31, 2016 21:24

Doctor w-rw-rw-: Jun 24, 2008

Swift code:

//: Playground - noun: a place where people can play

class SuperType { }
class SubType : SuperType { }
class OtherSubType : SuperType { }

class A { }

// Declared far away from classes A or B
extension A {
    func doSomething(general: SuperType) -> String {
        return "A.doSomething(general): \(general)"
    }
}

class B: A {
    // Marking as override impossible, because it's not an override
    func doSomething(specific: SubType) -> String {
        return "B.doSomething(specific): \(specific)"
    }
}

// -----

// This scenario seems pretty easily possible:
let someFunctionReturnedMe: SuperType = SubType() // Function returns one of the subclasses
B().doSomething(someFunctionReturnedMe)
// Outputs "A.foo(general): SubType"

let someVar = SubType()
B().doSomething(someVar)
// Outputs "B.foo(specific): SubType"

// Oops! Because of how we declared the variable, it resolved the ambiguity differently!
// If only we could avoid this with an obviously named API method.

// -----

// In case it's useful, a reference of what happens:
// 1. A with OtherSubType calls A.doSomething
A().doSomething(OtherSubType())
// Outputs "A.doSomething(general): OtherSubType"

// 2. A with SubType calls A.doSomething
A().doSomething(SubType())
// Outputs "A.doSomething(general): SubType"

// 3. B with SubType calls B.doSomething
// Still works if B.doSomething is deleted � calls non-override A.doSomething
B().doSomething(SubType())
// Outputs "B.doSomething(specific): SubType"

// 4. B with SubType and cast calls A.doSomething
B().doSomething(SubType() as SuperType)
// Outputs "A.doSomething(general): SubType"

// 5. B with OtherSubType calls A.doSomething
B().doSomething(OtherSubType())
// Outputs "A.doSomething(general): OtherSubType"

Spent some time revising my example. Hopefully this better illustrates a couple of ways in which it's problematic.

squidgee posted:

Also, I'd be remiss if I didn't point out that we've all just spent several pages bike shedding.

Hey, I've been writing code to try to demonstrate ways in which it obstructs unambiguous code inspection, which, as writers of code, we also constantly do (reading code)

# ¿ Jan 31, 2016 22:00

Doctor w-rw-rw-: Jun 24, 2008

Toady posted:

Overload gotchas are a known quirk--what I was getting at with regards to APIs that avoid AnyObject was the convention of using a protocol type, though overloads can still be introduced via extensions and subclasses (at least until final is default). At that point, I still don't see people's bad decisions as a strike against the style change.

It's less reasonable when a perfectly understandable Objective-C API turns into a Swift equivalent with gotchas, and even if I don't write bad code, I still have to expect it, and now that there could be gotchas I can't see immediately on code inspection, the change creates vastly more opportunities for me to fail to detect bugs.

# ¿ Feb 1, 2016 00:03

Doctor w-rw-rw-: Jun 24, 2008

Toady posted:

Objective-C's verbose style has its roots in an era when all objects were id and methods returned self by default.

The message passing syntax has its roots more in Smalltalk than old limitations, though.

Toady posted:

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.

They don't feel anachronistic at all. They're more textually clear and yeah, maybe that's because the used to need to be. Is there duplication in syntax along with type metadata? Sure. Do I want to be constantly figuring out that type metadata in my head while reading code? Hell no. That's unproductive and tiring.

Toady posted:

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.

Having taught programming before, the idea that the greater character count is more intimidating is absolutely preposterous. I can build confidence by saying "this function creates a string *points finger* "byTrimmingCharacters" *points finger* in a character set *points finger*. The second one? I need to make sure they're comfortable with the documentation and hope they remember that alongside everything else they're learning. The verbosity is a big strength because it feeds the mental associations to them rather than requiring them to keep them around, which benefits me in my ability to scan the code and know what exactly what is being called, as well as the ability to reason very quickly about a method that isn't currently in my working memory.

Also, it's no worse for typing unless the teacher is awful and doesn't teach their students to autocomplete extremely often.

Toady posted:

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.

That sucks, sorry :/ I'm sort of the opposite; concise languages irritate me greatly and I read them slower as a result.

Doctor w-rw-rw- fucked around with this message at 02:01 on Feb 1, 2016

# ¿ Feb 1, 2016 01:59

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

This is an interesting point, but it's pretty much inherently in conflict with trying to use consistent method names across types. For example, NSArray has a slicing operation called subarrayWithRange:, and NSString has one called substringWithRange:. In Swift that would have to be subcollectionWithRange:, at least until someone decides that there's a meaningful level of abstraction below Collection that can still be sliced.

Why is it necessary to coalesce two operations which, while conceptually similar, typically have different purposes? Unless you're planning on making Strings and character arrays exactly synonymous, the utility of identical method names is at best neutral. But hey, let's introduce API churn because minimizing the amount of similar methods named for their purpose instead of their implementation is ~elegant~.

While there may be an mapping from the old way to the new way, it's still breaking the crap out of APIs at a rather fundamental level. And the translation is, importantly, visually lossy. Objective-C's (and Swift's until now) verbosity has, in addition to the visual advantage, a pedagogical advantage as well � in that what you see is what it does.

This stems from my belief that Objective-C's naming conventions are, fundamentally, good � and that they are helpful to developers. It's a way more visually informative language than others, and that helps with learning, helps with inspection, and enables the creation of very obvious APIs.

<rant>

https://swift.org/blog/swift-api-transformation/ posted:

This is no mere aesthetic concern; non-uniformity and lack of predictability make everything harder, from coding to debugging to maintenance. Fortunately Swift developers created tons of great code in spite of that gap, and along the way, there evolved a sense of what �Swifty� code looks and feels like.

This rings so incredibly false to me. Objective-C's APIs are very helpful for predictability, and makes teaching, coding, debugging, and maintenance easier. I think great Swift code has been created because of this. I hesitate to throw a stronger tantrum (forgive the couple of next paragraphs), but drat, if this change goes through I struggle to imagine the day where I prefer to wrap a Swift core with an Objective-C API rather than write an Objective-C core with Swift, for projects where I want to support both.

It blows my mind that such a far-reaching and fundamental transformation is happening to Swift at this point. I understand that if it's ultimately a positive change, it should happen sooner rather than later. But the case for it is incredibly weak to me, the benefits so minuscule, and the disadvantage very real.

Does the Swift team seriously believe that systematically parsing and extensively munging patterns in not-quite-natural-language is tractable to support all the corner cases for? And that, even if it were, that it could avoid confusion in less-than-perfect codebases? The idea that this will somehow benefit a language, particularly one in which clear and obvious bridging is so vital is insane. The best it can do is a reasonable job, with some amount of either unfixable brokenness forced upon developers in perpetuity, or constant churn stemming from perpetual fixing of brokenness. Swift's translation is currently simple to reason about, and the language as a whole has got a really great thing going on. I'm really happy with where it is at this moment. Why ruin it by boneheadedly detonating the utility of two years of progress in literature and the library of online information about Swift? Seriously, why?

Imitating the Python 2 -> Python 3 transition, except with better translation tools, and even more API disruption, when the language is currently so promising , is incredibly distressing. It doesn't make sense!

</rant>

# ¿ Feb 1, 2016 20:18

Doctor w-rw-rw-: Jun 24, 2008

Thanks for the quote :blush:

# ¿ Feb 2, 2016 21:00

Doctor w-rw-rw-: Jun 24, 2008

On the bright side, it should be possible to write class extensions to wrap/reverse the transformations, right? Except when boolean properties overlap API transformations, I guess.

Also, for shits and giggles, and to demonstrate how easy it is to create a situation where you have to be aware of the conversion rules, try and figure out how this ridiculous method would be translated:

Objective-C code:

@interface Bling : NSObject
+ (Bling *)blingByBlingBling:(Bling *)bling;
@end

Use the proposal if you're stumped, and keep in mind that 'bling'' is also a verb.

EDIT: or, and I haven't checked this one yet,

Objective-C code:

@interface Bling : NSObject
+ (Bling *)blingByBlingBlingBling:(Bling *)blingBling;
@end

Doctor w-rw-rw- fucked around with this message at 22:13 on Feb 2, 2016

# ¿ Feb 2, 2016 22:10

Doctor w-rw-rw-: Jun 24, 2008

Dave Abrahams posted:

No, really, I'm in the clarity team.

Dave Abrahams posted:

It is true that you can't know what context an API will be used in. Does that mean you should preemptively build in as many clarifications as possible in case the context leaves usage unclear?

Yes, that doesn't sound too unreasonable. Sounds goo�

Dave Abrahams posted:

IMO, no.

# ¿ Feb 4, 2016 00:03

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

No, there is not a literal clarity team. Dave is the lead of the (very small) standard library team. He has been teaching programming and working in language communities and standardization efforts for several decades, and he treats this kind of community communication as a very serious and almost sacred duty, to the point of being a major and unending distraction to his other work. Acting like he's being some sort of argumentative rear end in a top hat because you decided to have a Funny Internet Reaction and don't like what he's saying is pretty loving uncharitable.

Who's calling him an rear end in a top hat? It's just funny that he created a straw man that was not only reasonable, but the way things have been. I do want my APIs to have a lot of information baked in to them.

For the benefit of others, here's the non-cherry-picked quote:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008904.html posted:

No, really, I'm in the clarity team. The same rules that go for English
go here. Clarify what's ambiguous, or that you can't easily get from
context. Clarifying things that are readily available from context just
makes code/prose/whatever *less* clear.

It is true that you can't know what context an API will be used in.
Does that mean you should preemptively build in as many clarifications
as possible in case the context leaves usage unclear? IMO, no. If each
of our words came pre-loaded with clarification, it would make ordinary
sentences unmanageable.

The author of an API cannot guarantee clarity at the use-site. The best
she can do is to provide the user of the API with the tools needed to
make use-sites clear. But part of that is a responsibility not to force
detail into the use-site that isn't going to be helpful in most cases.

With that said, fighting for language purity in a way that worsens developer ergonomics is wrong and I disapprove of his viewpoint, because it is a) complex, b) can't be implemented perfectly, yet can't be undone without even more massive disruption, and c) is a problem for essentially the entire rest of Swift's life. And that's independent of my disagreement with his statements with regards to teachability and clarity. It seems to me that his head is much more grounded in the concepts, whereas I am a much more visual person that scans code more effectively when it has the words there, just like I do with Java.

The whole proposal is creating ridiculously complex rules in comparison to the ridiculously simple rules to completely change...what? The aesthetics of the language to be more exactly like some embodiment of the language which the language does not itself meet? To distinguish it from the very thing it's fundamentally bridged with? In a way that must systematically apply not just once (to Cocoa), but again and again, to any code written in the very, very, established old way in the other language? After two years of working and working well? Congratulations, this is a problem that will last for the entire rest of Objective-C's life, which at this rate, is probably not going to die for a very, very long time.

EDIT: word choice happen -> die

Doctor w-rw-rw- fucked around with this message at 03:37 on Feb 4, 2016

# ¿ Feb 4, 2016 03:26

Doctor w-rw-rw-: Jun 24, 2008

sarehu: Well, goons have talked poo poo about my previous employer, previous CEO, and previous coworkers for a very long time. But perhaps it isn't the nicest thing and I've grown too thick a skin.

Echo Video posted:

legibility is relative, get over yourself

Legibility is relative, which is why brevity, having fewer clues, is less clear to more people.
--

I thought the humor would come off as slightly amusing rather than as a personal attack, and didn't intend to paint him as an rear end in a top hat, so for what it's worth, I'm sorry for that, rjmccall.

To restate some of how I feel in a way that is hopefully less confrontational: I think that the naming change is a catastrophe. That this change doesn't seemed to be acknowledged as a bad thing is really unfortunate. It won't stop me from writing Objective-C code, but it will make me more wary of writing Swift for a while. I care a lot about this change, because it removes something I really like about Swift, which I think is also valuable across the board from newbies to veterans. It's not that I can't adapt, or won't (given time), it's that it will make the experience of developing with Swift significantly less fun, so if I'm going to be writing code day in and day out, I'm going to prefer the other thing for a long time. With so much inertia behind Swift at this point, I find unpleasant the prospect of having the language as I know and enjoy it altered so dramatically.

# ¿ Feb 4, 2016 05:29

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

You do need to understand that we do this all day, every day. For every thread on that's a massive cluster-gently caress on swift-evolution, I assure you that we've had probably at least an order of magnitude more discussion internally, and those internal conversations are much more charged than mailing lists, both emotionally and politically. That's not to say that you should just shut up and let us have "our way"; very few proposals are going to gain perfect consensus even within the core team, and the community absolutely shapes the discussion. But the endless discussion is tiring, and it's hard to engage with every person with perfect deftness and attention, and there may even be other things happening in our work and personal lives besides language design, and we are human. If you show up in a conversation, and your post seems theatrically over-the-top, vitriolic, or in any other way unlikely to lead to a constructive conversation, it is very likely that you will simply be ignored, and you will have just made our lives worse, and we will not thank you for it. So, using the present example, when you call a proposal catastrophically bad and talk as if it's stripping all contextual information from the code and will forever stain your memory of Swift, and we know that the actual proposal does not have that large of a line-by-line impact on actual programs, it does not inspire credibility.

Part of why I made sure not to comment on the official mailing lists:

Doctor w-rw-rw- posted:

I hate when people (read: HN users) pile on to (for example) GitHub issues and offer comments without committing to a discussion and end up adding noise instead of useful commentary, so I'm not really willing to participate directly since I'd prefer to be writing code or ~~poo poo~~posting/discussing here instead of ignoring/forgetting to participate elsewhere. FWIW, I'm fine with my post being excerpted or reposted elsewhere, if it's actually worth sharing.

My 'professional' hat isn't on here, and I knew my reaction was negative enough that I wouldn't want to dip into a setting where good people are doing good jobs � and certainly not where I might represent my views as being anything but my own. The proposal feels super bad, but I don't want to barge into a professional setting with my (very) strong negative reaction.

You might be rightfully pissed with me at how over the top I get on an internet forum and stepping on your toes while doing so, but I do appreciate all of the above (plus what Subjunctive mentioned); next time we meet I'm also up to cover drinks.

rjmccall posted:

So it has always been clear that some things will look and feel different in Swift from how they do in Objective-C, because some methods simply would not have had exactly the same names if they were written in Swift. One way to remedy that, of course, would be to go through the entire SDK, method by method, and decide how they should be imported into Swift; but even if you got perfect up-take (impossible) and established very strong guidelines that everybody agreed on (impossible), you'd get different maintainers interpreting them differently enough to end up with an extremely non-cohesive environment. So even then, it would be better to try to automate the application of those guidelines. That's certainly possible: the technical aspects aren't difficult, and the exact algorithm isn't really important: the Swift programmer will see the imported API, and if the decision was really that bad, they can change it (by, at worst, wrapping it in their own API). Independent of the actual guidelines being applied, I don't think the idea of automatic application is itself problematic.

Agreed with respect to a lot of the text I snipped out, but I would actually prefer an automatically generated mapping into a format that can be manually edited for exceptions to the rules. Controlling the evolution of an API is really important, and when the evolution of that API is tied also to the version of the compiler being used, then it constrains improvement because now the compiler has to carefully manage what it breaks and when. And with hybrid libraries supporting both Swift and Objective-C, I just know that at some point I'll waste time fixing or debugging an issue specifically related to a corner case, and I'll remember this frustration and think "drat, this is so obviously wrong". I'd much rather the API translation not be tied to other code lifecycles, and perhaps Apple improves the mapping for their own libraries, re-generates the API, creates compatibility shims in the meantime while it deprecates the old Objective-C selectors (assuming Swift-first) or Swift methods in one iOS version, and removes them the next.

This way, you get to solve the problem for people, and let people either shoot themselves in the foot or aim the gun away from it instead of taking responsibility for developer frustration on account of a very disruptive change.

EDIT: so it occurs to me that a user*-defined mapping could have a non-trivial memory requirement to register the mapping, whereas the automatic mapping would be a lot cheaper and could be less constraining on some aspects of implementation. Given that, it seems more clear why any change needs to be comprehensive. I still disagree with a lot, but the "obvious" way to solve it in my head isn't necessarily good. Guess I need to keep writing Swift so I can argue more cogently.

* (as in developer of the thing that needs a mapping)

Doctor w-rw-rw- fucked around with this message at 10:03 on Feb 4, 2016

# ¿ Feb 4, 2016 09:36

Doctor w-rw-rw-: Jun 24, 2008

https://twitter.com/ashfurrow/status/715941778621206529

# ¿ Apr 5, 2016 17:54

Doctor w-rw-rw-: Jun 24, 2008

TheReverend posted:

Would you agree the potential to write godawful loving spaghetti code is now also greater? Seems like a lot of the "benefits" of swift could easily be abused and make everything worse for everybody.

You haven't written much Objective C++ have you

# ¿ May 4, 2016 20:35

Doctor w-rw-rw-: Jun 24, 2008

IMO C++/Objective-C++ interop would be a big deal towards adopting it, at least in the minority (?) of shops that make extensive use of either.

ComponentKit is dependent on Objective-C++ because the initialization syntax is superior, and no inline hierarchical markup syntax exists for us to use. I imagine if this were not the case there would be a massive effort to migrate to it ASAP.

# ¿ May 11, 2016 21:24

Doctor w-rw-rw-: Jun 24, 2008

n4 posted:

Ever since I've started learning Swift I wish everyday JavaScript could just be swapped out for Swift entirely. So I'd be very excited if that happened.

While that would indeed be glorious, React's popularity makes a syntax for inline component hierarchy definition a prerequisite for that. I think Apple (and others) underestimate the value in doing so.

Also, speculation - I bet if webassembly becomes a thing, we'll be seeing any number of languages finally able to script the browser. I imagine writing Swift for client-side web could be feasible in two to four years.

# ¿ May 12, 2016 09:35

Doctor w-rw-rw-: Jun 24, 2008

pokeyman posted:

Maybe I'm misunderstanding what "a syntax for inline component hierarchy definition" is, but why don't Swift enums fit that bill?

Am I missing something? Enums can't be subclassed, and enums can't have arrays for default values. Not to mention that components can still be kind of stateful in some corner cases. I can't envision it being cleaner than Objective-C (with the C++ part for cleaner inline syntax).

pokeyman posted:

Why do you think people are underestimating the value of a syntax for inline component hierarchy definition?

Andy Matuschak, ex-Apple (UIKit) posted:

Q: What effect do you think Swift will have on Apple�s framework APIs? Do you expect something here in the short term?
A: I don�t actually have insider knowledge here, so this is just speculation, but I think it will be a long process. At least when I was there, the teams spent the majority of their time not maintaining and improving frameworks, but really supporting market features like new screen sizes or support for new hardware. That�s what takes most of the time. So it will take a conscious decision to do anything non-trivial, and I don�t see that forthcoming.

It sounds to me like Apple teams (aside from devtools/compilers) struggle to push software meaningfully forward in a way other than line items in a slide on Apple's next hardware unveiling. Even if an engineer wanted to support a dramatically different but proven model for building UIs, they'd face a lot of institutional pressure against it. Some ex-Apple engineers I've talked to have expressed similar disappointments, though to be fair, them being ex-Apple, the likelihood of that is higher.

For others, I imagine it's lack of experience with the ideas, association with Javascript (though inline XML has been a thing in PHP for longer than it has in JS, and Scala does it too), and overinvestment in the wrong technology (i.e. autolayout).

Doctor w-rw-rw- fucked around with this message at 06:19 on May 13, 2016

# ¿ May 13, 2016 06:15

Doctor w-rw-rw-: Jun 24, 2008

pokeyman posted:

Neither JS nor PHP have XML literals though? I'm not really sure what your point is here, with that or with the grousing about Apple dev teams' management. What part of ComponentKit, or React, or whatever is fundamentally untenable in Swift today?

XHP and JSX. The difference is that a complete component instantiation can get very deeply nested and full of parameters, so lack of a clean syntax throws readability down the drain pretty quickly.

My Apple grousing was out of line. I feel frustrated at Apple because there are a couple of chasms they could cross, technologically speaking, but aren't. But they did with Swift, so...argh.

# ¿ May 13, 2016 17:00

Doctor w-rw-rw-: Jun 24, 2008

FYI

http://thread.gmane.org/gmane.comp.lang.swift.evolution/17276

Chris Lattner posted:

That said, it is also clear at this point that some of the loftier goals that we started out with aren�t
going to fit into the release - including some of the most important generics features needed in order to
lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a
future release of Swift, where I expect them to be the *highest* priority features to get done.

tl;dr: still gonna have to include the Swift runtime for a couple of years yet

# ¿ May 16, 2016 18:40

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

You would have anyway unless you've got a really aggressive deployment target.

Yes, of course. It just means another hypothetical year of waiting for shops that do current minus N iOS versions (or wait for % adoption to fall a sufficient amount based on that), in order to reduce app size.

# ¿ May 16, 2016 23:18

Doctor w-rw-rw-: Jun 24, 2008

emoji posted:

I'm sure Facebook is 123mb and Yelp is 74mb because of swift dylibs....

I know what you're trying to say but you're kind of correct, except the opposite of that.

# ¿ May 18, 2016 11:05

Doctor w-rw-rw-: Jun 24, 2008

Some commentary on dynamism in Swift: http://mjtsai.com/blog/2016/05/21/dynamic-swift-2/

# ¿ May 24, 2016 15:46

Doctor w-rw-rw-: Jun 24, 2008

https://www.twitter.com/mxcl/status/763957931616325632

# ¿ Aug 12, 2016 16:35

Doctor w-rw-rw-: Jun 24, 2008

ultramiraculous posted:

Am I an rear end to say I'm not super-surprised?

Could you explain why you're not super surprised?

# ¿ Aug 12, 2016 23:36

Doctor w-rw-rw-: Jun 24, 2008

Trying Swift again. Swift won't let me "let x: Foo<Any> = something", where something is Foo<Bar>. Trying to wrap my head around a non-type-erased system. Am I doing something wrong here?

# ¿ Oct 3, 2016 07:22

Doctor w-rw-rw-: Jun 24, 2008

Flobbster posted:

Generics aren't covariant in Swift. Imagine that Foo<T> is a type that has a writable property of type T or a method with an argument of type T. The statement you're trying to write would assign a Foo<Bar> to a variable that would let you set a property or call a method with an Any when it's expecting a Bar.

Well, crap. Time to throw out the generics, then. I originally wrote the thing in ObjC then decided I wanted to try writing it in a way that would run on Linux too.

# ¿ Oct 3, 2016 07:46

Doctor w-rw-rw-: Jun 24, 2008

Starting to play with the swift package manager. Feeling pretty good about it so far, especially since it works well with Xcode.

Are there any good Swift 3 command line parsing libraries?

# ¿ Oct 10, 2016 00:01

Doctor w-rw-rw-: Jun 24, 2008

I strongly suggest the Server APIs (https://swift.org/server-apis/) people not implement HTTP and WebSockets in a one-off way, and take the approach of netty or Wangle.

Facebook uses Wangle, which is basically a C++ version of Netty. Netty is a Java framework which is an extremely effective and lean networking framework in use by many companies, even hedge funds (where latency and performance is paramount). Twitter also uses (or used, I don't know what they're doing at this point) Netty via Finagle, a Scala layer on top. Netty's biggest advantage besides performance is that it is very composable, so it's also useful for many different kinds of daemons or API gateways.

Jersey is also another potentially interesting thing to look at for creating servers, but given that it leverages a lot of Java features it might not be as relevant.

# ¿ Oct 26, 2016 07:26

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 18:06

Doctor w-rw-rw-: Jun 24, 2008

Okay. Random interjections and dropping he mic is what I do best!

# ¿ Oct 26, 2016 17:38

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

«‹›3 »