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

[John Heerema]

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.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.xml
Type: application/xml
Size: 3222 bytes
Desc: default.xml
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160402/c62e68e4/attachment.wsdl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default[1].xml
Type: application/xml
Size: 3222 bytes
Desc: default[1].xml
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160402/c62e68e4/attachment-0001.wsdl>