[swift-users] "business applications market" flame

[Dru Satori]

Funny thing. I was moving towards swift and this discussion has helped me mcommit to more swift not less. I don't mind limitations if I understand them going in

Sent from Outlook Mobile<https://aka.ms/qtex0l>




On Fri, Jan 8, 2016 at 10:28 PM -0800, "Don Wills via swift-users" <swift-users at swift.org<mailto:swift-users at swift.org>> wrote:

Jens -

I apologize for having annoyed you, but this thread has been very informative for me.

I was under the misconception that Swift was more similar to Java and .NET than to C, C++ and Obj-C.  Your statement - The designers of Swift do not like exceptions. - clears up some of my misunderstanding of fundamental principles guiding Swift design.  And thank you Brent Royal-Gordon - your explanation was of great help in furthering my understanding of those design decisions.

I was seriously considering moving toward the use of Swift as the programming language of the future for my companies' mission-critical business application systems, but the knowledge I've gained in this thread has disabused me of that.

Sincerely,
Don Wills
owner, Produce Pro, Inc. and Portable Software Company


On Jan 8, 2016, at 10:55 PM, Jens Alfke <jens at mooseyard.com<mailto:jens at mooseyard.com>> wrote:


On Jan 8, 2016, at 6:38 PM, Don Wills <don.wills at portablesoftware.com<mailto:don.wills at portablesoftware.com>> wrote:

All I am asking for is that the "throws" keyword on a method definition be optional - that is, a method can throw a <thingy> with the throw statement without specifying "throws", and it can be caught by a matching try/catch clause up the stack.

That's asking for much, much, much more than making a keyword optional. You're asking for the underlying error handling mechanism to be something completely different than what it is, i.e. stack-unwinding exceptions rather than returning an error value.

That is perfectly possible with LLVM and does not entail any ill-defined behavior.

There is a vast difference between machine code supporting something, and a language supporting it. You could say the same thing about nearly any language feature that Swift decided not to support. "But LLVM allows multiple inheritance!" "There's nothing in LLVM preventing making all value bindings immutable!" "LLVM supports goto statements!"

The designers of Swift do not like exceptions. They decided not to include them in the language. Arguing for exceptions here is a tiresome religious war. When I worked at Apple I had some arguments about exceptions with people on the Cocoa and compiler teams. I definitely prefer exceptions to plain old return values (as in C or Go or Swift 1.x), but the compromise in Swift 2 is good enough that I'm happy with it, and I appreciate arguments like Brent's about the overhead it saves. (If you've looked t the disassembly of exception-heavy C++ code, you can see all the code-size overhead it adds.)

All language designers have features they dislike and won't add. Try arguing for late-binding dynamic dispatch to C++ gurus. Try arguing for explicit "free" calls in a Java forum. Tell the Haskell maintainers that mutable variables make coding so much easier. If you think language designers should give in and add every feature someone thinks is important, then you get the real kitchen sink you keep saying Swift is.

That's the last I'm going to write about this. It's stopped having any value. I've been around long enough to be sick of language flame wars, and that's about all this is.

-Jens


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160109/d0a6ce60/attachment.html>