[swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Jamie Lemon]

I guess you don’t like Swift then after all?

In my humble experience I have been involved in writing iOS apps since 2008 so seen a few changes - I have found it quicker and easier to write in Swift and just get things done better ( compared to Objective C ).

For me - Swift is most welcome, very refreshing and has more clarity than Obj C. It has been nothing but a pleasure to move on from Obj C.

So keep up the great work guys please!!!!!

p.s. I like how easy to use tupules are - if people don’t like them or it’s not their style then just don’t use them huh?


Jamie Lemon


On 11 Jan 2017, at 12:01, Freak Show via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

I am almost not sure if this is a joke or not.  That is an incredibly complicated looking hieroglyphic to dispatch a bit of code.  I do this:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    NSString* message = [NSString stringWithFormat: @"prepareSeque%@To%@:",(segue.identifier ? segue.identifier : @""), [segue.destinationViewController class]];
    SEL method = NSSelectorFromString(message);
    if([self respondsToSelector:method])
    {
        [self performSelector:method withObject:segue.destinationViewController];
    }
}
// Assume segue identifier was NextStep and we are going to a NextViewController
-(void)prepareSequeNextStepToNextViewController:(NextViewController*)vc
{
    // do specific work in a small focused method instead of buried in a giant ugly switch statement
}

Burying all that logic in a bunch of control statements just obfuscates intent.  Now, you may argue my prepareForSegue is a little bit ugly and I would agree with you - but I write that once, stick it on UIViewController as an extension method, and never look at it again, instead going off the naming convention - much like the responder chain works.

I keep hearing the same justifications over and over.  "Compiler can't check that", "pattern matching", "powerful enums", "protection from nil", "faster execution", "exhaustively checked switch statements" etc.... I do not value any of that stuff and it all goes out the window once your program beings consuming data from outside.  It doesn't make my programs more powerful, more expressive, more robust, or better.  It does slow me down a lot trying to satisfy a bunch of constraints that are, frankly, irrelevant to my problem domain and what it does instead is refocus my attention from the problem domain into the implementation domain unnecessarily.

The conventional wisdom is that switch statements are an anti pattern in the presence of OO features.  They're brittle and basically they're goto's.  Polymorphism is to be preferred. I thought we settled that in the 90s.

It is becoming more and more clear that the ideals of Swift are nothing like the Smalltalk ideals that gave us Cocoa (and Cocoa is a very elegant framework loaded with beautiful design patterns that have served us very well - well enough to let little Apple eat Microsoft's lunch).  Swift is a lot closer to the ideals of C++ and ML and they are a terrible fit on top of a Smalltalk inspired framework.  Write Swift if you must - but stop screwing up the Apple app scene with it.

Seriously, I'm out.  I'd just like to ask the Apple people to stop dumping cruft into the Objective C header files.  I don't care about nullable annotations or the fake generics cruft.  Objective C is based on Smalltalk.  This direction is anathema to the Smalltalk ideals that underly the existing Cocoa system.  Nils don't matter and generics are nonsense in a dynamically typed world.  I mean, have any of you even used a book on Smalltalk as a doorstop much less read one?

Basically, you're killing the golden goose.  Like when WebObjects was ported to Java.  It didn't survive the change from dynamic language to more rigid type constrained Java language.  It just died.

Cocoa won't either.

I'm signing off this list. Swift is about the opposite of what I need in a programming language.  It will not scale to the enterprise any better than C++ did (clue - it didn't - I was there) and the embedded world has already had working Smalltalk implementations all the way down to fpga's (http://ieeexplore.ieee.org/document/564744/) for over 20 years so I'm completely unpersuaded by the efficiency arguments or the compiler checked "correctness" arguments.  Software is never correct, never done, never perfect.  Best to have an environment that can deal with that.

Oh and uh - stop pushing Swift as the future.  9/10 jobs doing iOS now demand Swift.  Thanks for that.  And by thanks - I mean screw you, Apple.  State of iOS development today is a disaster.

Out.

On Jan 11, 2017, at 00:04, André Videla <andre.videla at gmail.com<mailto:andre.videla at gmail.com>> wrote:

func prepareForSegue(segue: UIStoryboardSegue, sender: Any?) {
    Switch (segue.identifier, segue.destination, sender) {
        Case ("Segue"?, let vc as FirstVC, .some(.enumType(let value)) ): // prepare the vc
        ... // other segues
    }
}

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170111/c42a31be/attachment.html>