[swift-evolution] Revisiting 0004 etc. - Swift deprecations

[Ross O'Brien]

Because you're coming to the discussion late, the arguments you're making
are a little out of date. It's no longer a case of not removing these
features. It's now a case of having a compelling reason to put them back.

I trust you've read the proposals that were put forward. For the benefit of
those reading, they're here:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

There are several disadvantages listed for keeping these two features.
Those are the arguments you need to counter. As it happens, both proposals
refer to the metric of 'if this wasn't already in Swift, would it be
accepted for Swift 3?' and both features have been deemed to fail this
criterion. That's what you need to address.

Bear in mind these decisions were made several months ago, and both
features have already been deprecated as of Swift 2.2, which is now in use
in production code, many developers (including myself) are already
refactoring their code to remove uses of these syntax forms.


On Sun, Apr 3, 2016 at 12:45 AM, John Heerema via swift-evolution <
swift-evolution at swift.org> wrote:

> Warning - long post.
> I know that some folks really hate long posts, so let me apologize right
> now for this being a long post. Please feel free to skip right on past it.
> I posted it on a weekend, when there¹s less mailing list traffic, but that
> doesn¹t make it any shorter.
>
> Warning - revisits two approved deprecations.
> If you really, really hate it when people want to revisit decisions that
> have already been made, please just skip right past this post. My
> apologies for not contributing to the discussion when these decisions were
> originally being made!
>
> The day that Swift was announced at the WWDC was very
> exciting for me, and I immediately read the Swift book from beginning to
> end.
> Swift quickly became my favourite language: I felt that the Swift language
> developers had created a beautiful language that combined expressiveness
> with
> practicality in a way that made Swift code both powerful and easy to
> understand. Swift was crafted by some very smart and practical people.
>
> To put my thoughts into perspective, I should mention that
> I¹ve taught Computer Science at a senior University level for years, and
> have
> worked in industry for decades. As a computer scientist, I¹ve had a strong
> interest in computer languages for many years. I became an Apple developer
> upon
> purchasing an Apple Lisa a very long time ago.
>
> Over the past couple of years though, I¹ve seen what I think
> of as a growing emphasis on strict feature orthagonality at the expense of
> practicality in Swift. Perhaps this because much of the feedback on the
> language has been provided by those of us who are interested in computer
> languages. But for whatever reasons, the Swift language seems to have
> become
> more cluttered and less friendly.
>
> As I¹ve gone through the various beta releases, I¹ve seen
> changes that detract from the experience of using Swift, for reasons that
> seem
> related to ³language purity².
>
> I was finally moved to try to express my thoughts after
> seeing a couple of what I think of as particularly inadvisable proposals
> for
> Swift version 3 and beyond.
>
> Unary increment and decrement operators: ++ and ‹
>
> The first of these was the now approved removal of Swift¹s
> convenient unary increment and decrement operators. I would agree with
> some of
> the comments that have been made about these operators not being quite
> orthogonal with other expressive elements in the language. Nonetheless,
> they
> are a handy and popular way to iterate over enumerable collections, and to
> increment and decrement a variable that is used for purposes other than
> iteration. They also lend themselves to being extended to other data
> types, such
> as position pointers in linked lists, where they can implement the
> convenient
> concept of ³the next thing² (which += does not provide).
>
> The desire to get rid of these rather harmless operators
> reminds me of some of Apple¹s own history, and the history of computer
> languages in general. Niklaus Wirth didn¹t care for shortcut operators
> either,
> and so Pascal never got them.
>
> However, Apple eventually moved away from Pascal to C, even
> though C is in many ways a deeply flawed language that is responsible for a
> wide litany of software errors. Why? I personally really liked Pascal, but
> many
> (most) developers didn¹t care for the language. I¹d argue that developers
> preferred the flexibility of C to what they saw as the overly restricting
> constraints of Pascal.
>
> One of the surprising reasons that I heard a lot at the
> time, was that developers didn¹t want to lose C¹s shortcut operators. If
> Wirth
> had been willing to give Pascal some of C¹s convenience operators, things
> might
> well have turned out differently. Developers hate typing.
>
> The notion that there should be exactly one way to do a
> particular thing sounds like dogma to me: not practicality. If people are
> concerned that unary operators confuse beginners, I would encourage them to
> convince educators not to teach them to beginners. Anyway, there are a lot
> of
> things in Swift that can confuse beginners!
>
> Although it¹s hard for me to believe that having these
> operators return void has been seriously considered, I would argue that
> this
> would be even sillier than removing them. A lot of developers use both C
> (or
> Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
> operators
> act completely differently in Swift would be a great way to alienate those
> developers.
>
> Let¹s not forget that  Swift
> is not the lingua franca of the computing world. It¹s an upstart that
> needs to
> attract the development community. Why repel people coming from the various
> C-like languages without a really, really, convincingly good reason? it¹s
> better for an upstart to attract than to repel.
>
> Right now, there are an awful lot of developers who are used
> to, and like the convenience of unary increment and decrement operators.
> Removing them seems bound to annoy developers and diminish the popularity
> of
> Swift, in exchange for Š well, not very much except for a tiny bit of
> language
> purity. That just seems silly to me.
>
> C-style For loops
>
> Removal of C-style For loops has already been approved for a
> future version of Swift. Even though I find the C-style For loop to be a
> bit
> ugly and unintuitive, I believe that removing it was the wrong thing to do.
>
> It comes down to flexibility and expressiveness. The reality
> is that C-style For loops easily implement certain operations that are more
> difficult to implement without them.
>
> I¹ve seen comments that C-style For loops are ³hardly ever
> used², and that ³hardly any² algorithms really need them. I believe that
> ³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
> I
> don¹t use them, so I don¹t think that any anyone who¹s important uses
> them.².
>
> Yes, there are many cases in which I believe that Swift
> provides looping structures that are safer and easier to understand than
> the
> C-style For loop. I¹d even say most cases. But I work in the scientific and
> engineering domains, and can point to many instances of looping structures
> that
> are easily expressed with a C-style For loop, but are clumsy to implement
> without it.
>
> In the world of the natural sciences, there are any number
> of instances of loop increments that requires some kind of a calculation.
> There
> are any number of instances of dynamically calculated loop termination.
>
> Swift¹s stride has some nice features for simple increments,
> but also has some important limitations. Among them, it involves the two
> step
> process of first creating an enumerable set, and then iterating over it.
> In the
> natural sciences, it is not uncommon for complex loop increments to be
> used in
> loops that are executed millions of times.
>
> Conceptually, creating an enumerable set, and then iterating over it,
> reeks of the arrogance of assuming that computing resources are unlimited.
> Even
> though the compiler may optimize the stride into the loop structure, it
> feels
> like unnecessarily creating a gigantic enumerable set.
>
> Whether we like it or not, the enduring popularity of the
> C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
> alternative that also provides the same flexibility. So don¹t take it
> away. If
> you don¹t like it (I don¹t always either), think of something that is
> clearly
> superior in 100% of use cases. Even then, I would argue against removing
> it.
>
> I would argue that the C-style For loop implements some
> rather Swift-like concepts. The syntax provide for three closures: one
> each for
> (a) things to do first, (b) things to do when deciding whether to stop
> iterating,  and (c) things to do after each iteration. How is that contrary
> to the principals of Swift?
>
> Just like pretty much everywhere that Swift allows closures,
> they can be used to write code that is difficult to understand. But the
> syntax
> is general and flexible enough to have survived intact for half a century.
>
> It¹s the carrot vs. the stick. Developers prefer the carrot.
> The belief that we can force developers to write better code by taking away
> language features, has not historically met with success. Let me say that
> again, because I think it¹s important. Developers who are given a choice
> between C and a ³better² language (say Modula-2, or Swift) are unlikely to
> react favourably to being told ³we¹re taking away this feature of C that
> you
> like, for your own good, because you¹re too stupid to use it sensibly².
> Taking away well-understood expressive language elements, and replacing
> them with something less expressive, is not going to win developers over.
>
> C-style For loops haven¹t changed in half acentury, because they work.
> A lot of other languages have also adopted them, because they work.
>
> If I may, I¹d like to take the English language by way of
> analogy. English contains a lot of weird, irregular language elements.
> There¹s
> no single way to express a concept. Instead, there are many, subtly
> different
> ways to express yourself.
>
> But, for all of its weirdness, English has remained popular
> for centuries, whereas more ³sensible², ³regular² languages like Esperanto
> never caught on. The reasons are flexibility and expressiveness. The same
> thing
> applies to computer languages.
>
> If we only look inside the world of compilers and computer
> science instruction, to see if we need the flexibility of C-style For
> loops, we
> might mistakenly think that we don¹t. But those domains are relatively
> simple
> in comparison to the physical sciences. Our experience there doesn¹t always
> translate to the more complex world of physical reality. So let¹s not throw
> away convenient and useful language features just because we don¹t
> personally
> care for them.
>
> Don¹t make Swift Yet Another Interesting Experiment in
> language design that wasn¹t widely adopted, and
> ended up being relegated to the dustbin of history.
> It would make me sad to see the best new computer language
> in ages become just another niche language. We already
> have enough of those.
>
> So, all of you folks who voted to remove these things, please don¹t hate
> me!
>
> Regards,
> J. Heerema, Ph.D.
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> 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/20160403/3ea1b053/attachment.html>