Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift: Things I really wanted that won’t make it

ericasadun.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Swift: Things I really wanted that won’t make it

#21

Post by austinz »

chris_7 wrote: post #11
dikaiosune wrote: post #4

Error and Result types in the standard library, macros, per-target configurations and tests, a fix for namespacing issues due to the lack of a central repository for open-source libraries. The presence/lack of each of these are some of my favorite things about Rust, and it's too bad to see them miss this release of Swift.

Swift's error handling model essentially tosses type information out the window. I really don't understand why it was created instead of a first-party Result type.

I've seen interest on the lists for modifying the model to allow a single failure type to be specified. I hope someone will write up a proposal once August rolls around and the lists are open again to new feature ideas.

Re: Swift: Things I really wanted that won’t make it

#22

Post by chris_7 »

stcredzero wrote: post #17
chris_7 wrote: post #9

Earlier quoted context omitted.

Idiomatic Swift is primarily protocol-based, object-orientation is mostly used when talking to the Cocoa frameworks, which aren't idiomatic Swift code. But the main problem with subclassing is: https://en.wikipedia.org/wiki/Fragile_base_class

Back in the day, with Smalltalk, a programmer could override everything. If you did something that broke derived classes, you were simply being a bad programmer. You simply didn't do that, and if you couldn't deduce if your change would do this or not, you either had a badly architected system, or you were being a bad programmer. This is how it should work in many production environments: Are you 100% sure about that…

"final" allows the compiler to strictly enforce that "don't break things" idea, instead of delegating it to fallible humans. (it also lets the compiler make your code faster)

By using the tools that Swift provides - preferring value types, and falling back on final classes, I can much more easily deduce what my changes will do.

Non-final classes create an additional public API that framework authors need to support - the ability to change any behavior. Reducing the surface for potential errors makes frameworks and their clients more robust.

Re: Swift: Things I really wanted that won’t make it

#23

Post by chris_7 »

kbenson wrote: post #19
mikeash wrote: post #13

Earlier quoted context omitted.

You can nearly implement your version of `with` today: func with (value: T, f: T -> Void) -> T { f(value) return value } Which you could then use like: let task = with(NSTask()) { $0.launchPath = "/usr/bin/mdfind" $0.arguments = ["kMDItemDisplayName == *.playground"] $0.standardOutput = pipe $0.launch() $0.waitUntilExit() } The `let task =` part would be optional, and you could leave it off if you don't need to use t…

Okay, then I don't really see a reason for Erica's syntax,which is special and either ambiguous or limited. How do you know whether you are calling a method on the given object, or a plain function? How to you know whether you are using an attribute of the object or a variable? Just rely on scope? That seems far more problematic and error prone for the small convenience of not typing three more characters with object…

I'm not sure if the function call could be optimized out across module boundaries, that's really the only justification for this to be dedicated syntax I can see. It's somewhat obsoleted in Swift 3 regardless as SPM uses static linking, where it should be able to be optimized.

Re: Swift: Things I really wanted that won’t make it

#24

Post by adamnemecek »

Swift is not perfect but I've been writing it a bunch recently and it's hands down one of the most productive languages I've written in. Fundamentally I believe that it might be one of the most important languages because it's relatively close to the metal, it's a 'modern language' (i.e. functional, has a pretty good type system), open source, and a major company and platform behind it. I think that if Swift 4.0 adds concurrency to the language (as hinted), that we could see it defeat Go on the web.

Re: Swift: Things I really wanted that won’t make it

#25

Post by mpweiher »

kbenson wrote: post #10

> Disambiguating SPM Naming Conflicts Perl 6 did some work on this. I'm not sure if it's fully supported yet, but the design docs[1] go into detail on how it's supposed to work, so it may be worth looking at. > Method Cascades I suspect you might find disambiguating your method/attribute access easier in your "with" syntax if you make it match what swift appears to do for anonymous variables, use $0. (pardon my unfam…

In Objective-Smalltalk:

   task ← NSTask new.
   task setLaunchPath:'/usr/bin/mdfind';
        setArguments:#('kMDItemDisplayName == *.playground');
        launch;
        waitUntilExit.
Aside from the ';', no special syntax needed. And unlike other Smalltalks, there is a parallel with '|' for composition instead of cascade (so send the next message to the result instead of the receiver of the first expression), which helps disambiguating keyword syntax without requiring parentheses:

   'a' stringByAppendingString:'b' |  stringByAppendingString:'c'.
This is especially useful when building expression incrementally, as it doesn't require going back to the start of the expression. Of course, stringByAppendingString: isn't such a good example because the ',' message makes this quite a bit more compact:

   'a','b','c'

Re: Swift: Things I really wanted that won’t make it

#26

Post by joewillsher »

chris_7 wrote: post #11
dikaiosune wrote: post #4

Error and Result types in the standard library, macros, per-target configurations and tests, a fix for namespacing issues due to the lack of a central repository for open-source libraries. The presence/lack of each of these are some of my favorite things about Rust, and it's too bad to see them miss this release of Swift.

Swift's error handling model essentially tosses type information out the window. I really don't understand why it was created instead of a first-party Result type.

Here’s your explanation: https://github.com/apple/swift/blob/master/docs/ErrorHandlin...

There has been discussion about statically typed errors on the evolution mailing list — some core team members said they may look into in the future and others seeming more doubtful of its usefulness.

Why do you think a typed error handling model is better than introspecting the error at the catch site, I’m not sure I buy it?

Re: Swift: Things I really wanted that won’t make it

#27

Post by stcredzero »

chris_7 wrote: post #22
stcredzero wrote: post #17

Earlier quoted context omitted.

Back in the day, with Smalltalk, a programmer could override everything. If you did something that broke derived classes, you were simply being a bad programmer. You simply didn't do that, and if you couldn't deduce if your change would do this or not, you either had a badly architected system, or you were being a bad programmer. This is how it should work in many production environments: Are you 100% sure about that…

"final" allows the compiler to strictly enforce that "don't break things" idea, instead of delegating it to fallible humans. (it also lets the compiler make your code faster) By using the tools that Swift provides - preferring value types, and falling back on final classes, I can much more easily deduce what my changes will do. Non-final classes create an additional public API that framework authors need to support -…

By using the tools that Swift provides - preferring value types, and falling back on final classes, I can much more easily deduce what my changes will do.

No disagreement here.

Non-final classes create an additional public API that framework authors need to support - the ability to change any behavior. Reducing the surface for potential errors makes frameworks and their clients more robust.

Since Smalltalkers knew all their code was "surface," there was motivation to keep things very encapsulated. (Perhaps this is part of why the Law of Demeter was so big in that programming culture.) Synergistic with this, was the heavy use of the very powerful debugger. If your codebase was mostly relatively stateless or very well encapsulated, you could time-travel with ease in the debugger by unwinding the stack, recompile your method in place, and continue on. Conversely, if you wrote code that didn't have those qualities, your fellow programmers would get annoyed at you for making their lives harder and their tools much harder to use.

Increasing the surface makes frameworks more flexible and necessitates good design throughout. Is there a trade-off? Sure. The really good Smalltalkers spent lots of time reading code and exploring stuff in the debugger/browsers. And sometimes, you could be stymied because you couldn't rule out stuff and risk a blow-up in production. And to be fair, in my estimation, Smalltalk projects were less robust -- but got fixed really quickly.

Nowadays, I think the sweet spot would be in a simple language with super fast compile/edit/test cycles, with equally powerful debugging, and with type annotations.

Re: Swift: Things I really wanted that won’t make it

#29

Post by chris_7 »

joewillsher wrote: post #26
chris_7 wrote: post #11

Earlier quoted context omitted.

Swift's error handling model essentially tosses type information out the window. I really don't understand why it was created instead of a first-party Result type.

Here’s your explanation: https://github.com/apple/swift/blob/master/docs/ErrorHandlin... There has been discussion about statically typed errors on the evolution mailing list — some core team members said they may look into in the future and others seeming more doubtful of its usefulness. Why do you think a typed error handling model is better than introspecting the error at the catch site, I’m not sure I buy it?

Errors should be Just Another Value, so the difference between untyped errors and typed errors is the same as the difference between just using Any for every parameter and return value, and using actual types.

You can use Any for everything, and it can even be totally safe if you use as? correctly, but it's obvious why no one does that. It's not obvious to me why people are fine with that situation for errors - again, the catch-all handler issue mentioned above, and the bizarre special-casing of NSError.

Re: Swift: Things I really wanted that won’t make it

#30

Post by jbverschoor »

adamnemecek wrote: post #24

Swift is not perfect but I've been writing it a bunch recently and it's hands down one of the most productive languages I've written in. Fundamentally I believe that it might be one of the most important languages because it's relatively close to the metal, it's a 'modern language' (i.e. functional, has a pretty good type system), open source, and a major company and platform behind it. I think that if Swift 4.0 adds…

Fully agree. It's a very nice language to work with, and I'm amazed about the small number of bugs / programming mistakes I made with it.
Post reply on HN