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.
default.xml
Description: default.xml
default[1].xml
Description: default[1].xml
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
