<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi John,<div class=""><br class=""></div><div class=""><div class="">well, I certainly don’t want to return working with C or C++</div><div class="">(I am still recovering from working on C only project on OS/2 </div><div class="">back in 2002 :o) after this little nightmare I always tried </div><div class="">to avoid as much as possible working on C/C++ </div><div class="">and also Javascript projects...</div><div class=""><br class=""></div><div class="">Pascal was/is? ok too, I learned OOP with Turbo Pascal 5.5 </div><div class="">in 1989-90. (it should have been Smalltalk but (private) computers</div><div class="">were not fast enough back then) </div><div class=""><br class=""></div><div class="">If I was given the choice of using either C/C++ or OOP Pascal, </div><div class="">I would choose Pascal because due to its rigid structure it catches </div><div class="">a lot of programming errors at compile time instead of run time. </div><div class=""><br class=""></div><div class="">This is a very important aspect of Swift: </div><div class="">that it catches a lot of mistakes at compile time! </div><div class="">I am very grateful for that because it saves me</div><div class="">a lot of trouble at run time, let alone the embarrassment </div><div class="">of having to solve bugs in already distributed applications </div><div class="">(of course, you can’t prevent it all) </div><div class="">Unfortunately this is very hard with “totally free” languages </div><div class="">like C and C++ are. To me it is almost that C/C++ are a kind </div><div class="">of super-assemblers and therefore (still?) good for making </div><div class="">low-level system software. There is an old, albeit ia bit macabre, </div><div class="">saying that “C and C++ provides all the rope to hang yourself”.. </div><div class="">However, In the digital domain, for most of us I’d say </div><div class="">this is very true.</div><div class=""><br class=""></div><div class="">It is also therefore that Pascal has a more fool-proof</div><div class="">for-loop </div><div class=""><br class=""></div><div class=""> for < variable-name > := < initial_value > to [down to] < final_value > </div><div class=""> do</div><div class=""> /* statements */ <br class=""><div class=""> end</div></div><div class=""><br class=""></div><div class="">...or the 1964 PL/1 variant which has a variable increment/decrement value</div><div class=""><br class=""></div><div class=""><div class=""> do i = 10 to 5 by -1; /* "by 1" is the default if not specified */</div><div class=""> /*statements*/;</div><div class=""> end;</div></div><div class=""><br class=""></div><div class="">The variant I am suggesting for Swift is more or less based</div><div class="">on these Pascal and PL/1 implementations because they are safe, </div><div class="">natural and readable, even for beginners.</div><div class="">Because Swift does not offer easy-to-work-with similar variants</div><div class="">it is regretful that the Swift: </div><div class=""> for initialization; condition; increment/decrement</div><div class=""><br class=""></div><div class="">has been removed as written in Proposal nr. 0007, even</div><div class="">before offering a satisfying alternative. </div><div class="">I still don’t understand why the Swift core team has accepted </div><div class="">such a proposal, largely based not on facts</div><div class="">and adequate research, but mostly on very subjective criteria.</div><div class=""><div class="">Alas, but I have already described my opinion about </div><div class="">this proposal 0007 in a previous post. </div></div><div class=""><br class=""></div><div class="">However to return to the overall topic here: </div><div class="">Pascal, made by Niklaus Wirth offered imho a </div><div class="">“reasonable amount” of protecting the programmer </div><div class="">against one’s self, so that one does not encounter</div><div class="">pitfalls again and again, which does not only happen</div><div class="">with beginning programmers but also with </div><div class="">experienced digitally active ladies and gentlemen too.</div><div class=""><br class=""></div><div class="">Later on, Niklaus Wirth created Modula-2. </div><div class="">(and after that also Modula-3) </div><div class="">If one wants to see really good scope handling then </div><div class="">take a look how this is implemented in Modula-2 here:</div><div class=""><a href="https://en.wikipedia.org/wiki/Modula-2" class="">https://en.wikipedia.org/wiki/Modula-2</a></div><div class="">I think this could be a good base for the modularity</div><div class="">in Swift as well. </div><div class=""><br class=""></div><div class="">Back then in ca. 1991, I bought a Modula-2 language system</div><div class="">from TDI for my Atari 520 ST, although I found programming</div><div class="">with Modula-2 on many occasions a bit too restrictive. </div><div class="">However, I quickly noticed that my apps made with Modula-2</div><div class="">were more stable with very little run time bugs or memory </div><div class="">runaways.. </div><div class=""><br class=""></div><div class="">So some protectionism is a good thing, </div><div class="">this is what Swift offers too, which I really appreciate.</div><div class="">but to what extent does this need to be enforced?</div><div class="">How far does one go? </div><div class="">Imho, that is exactly what we should discuss.</div><div class="">It is about the range between too rigidly enforcing restrictions</div><div class="">and making a language “totally free” </div><div class="">Both have it’s pros and cons. </div><div class="">The art then is, to find the silver path in between</div><div class="">these extremities. A dogmatic approach</div><div class="">(on either side) is not really very helpful.</div><div class=""><br class=""></div><div class="">TedvG</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 05.04.2016, at 03:30, John Heerema <<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">Thanks! I enjoyed reading your post today.</div>
<div class=""><br class="">
</div>
<div class="">I don’t see having two ways to do something as a weakness, but a strength.</div>
<div class="">Again, that’s why weird-old English won out over Esperanto.</div>
<div class="">And why messy-old C won out over Pascal and Modula-2 (and, if we’re not careful, Swift).</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">John</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>"Ted F.A. van Gaalen" <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Monday, April 4, 2016 at 1:40 PM<br class="">
<span style="font-weight:bold" class="">To: </span>John Heerema <<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>><br class="">
<span style="font-weight:bold" class="">Cc: </span>swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Hello John</div>
<div class="">I subscribe completely to this point(s) of view!</div>
<div class="">TedvG</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">Date: Sun, 3 Apr 2016 19:25:09 +0000<br class="">
From: John Heerema <<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>><br class="">
To: "<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>" <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">
Subject: Re: [swift-evolution] Revisiting 0004,<span class="Apple-tab-span" style="white-space: pre;"></span>0007 etc. - Swift<br class="">
<span class="Apple-tab-span" style="white-space: pre;"></span>deprecations<br class="">
Message-ID: <D326CA33.B1738%<a href="mailto:jheerema@ucalgary.ca" class="">jheerema@ucalgary.ca</a>><br class="">
Content-Type: text/plain; charset="windows-1252"<br class="">
<br class="">
Thanks to all those who thoughtfully responded to this post! The folks who responded provided kind thoughts and advice.<br class="">
<br class="">
Ross O’Brian asked if I was familiar with the original discussion for 0004 and 0007.<br class="">
<br class="">
To answer: Yes, I read the discussions several times over a period of a few weeks before writing anything myself. Unless the repo is somehow missing an awful lot of discussion, I would say that both of these proposals received startlingly little discussion
at the time. These are very early proposals (numbers 4 and 7), and were conducted before a lot of people (including me) had any idea that feedback was being solicited.<br class="">
<br class="">
My thoughts on these deprecations are aimed more at the human side of how developers actually behave, than on the strict “desirability" of the deprecated features.<br class="">
<br class="">
Let’s take proposal 0004 – to deprecate the ++ and — operators.<br class="">
<br class="">
A few years ago, I’ve have chimed in to say “sure, let’s deprecate those things. += is more general and obvious”. But that’s how those of us who think about orthogonality think.<br class="">
<br class="">
On the human side, what do the human being who write code actually do?<br class="">
Human beings notoriously do not act in the way we think they “should”.<br class="">
<br class="">
Lots of languages, like C, C++, C#, Objective C, Java, etc., already have both the prefix and suffix versions of ++ and --.<br class="">
All of those language also allow developers to use += 1. So, each and every one of the millions of people who use those languages already have a choice of using any of:<br class="">
a = a + 1<br class="">
a += 1, or<br class="">
a++<br class="">
<br class="">
So an enormous social experiment has already been done, and we can benefit from it, if we are willing. Given that millions of people have already been given the choice of using any of the three forms shown above, what do they actually prefer to use? There are
many, many millions of lines of extant code that can be parsed to determine what developers actually use when they are given the choice.<br class="">
<br class="">
I’m pretty sure that everyone on this list already knows the answer, and it’s not the choice we might think that all those millions of developers “should” have made. Given a free choice, developers overwhelmingly chose to use ++ and —. They predominately use
the suffix version, but the prefix version is also common. If you don’t believe me, it’s easy to find out for yourself. Actually, I would encourage you not to believe me. Please conduct your own experiment if you have access to a significant body of code.
At a more personal level, did you have to refactor your own code to eliminate them? Of course it's easy to do, but why didn’t you make the “right” choice in the first place?<br class="">
<br class="">
So, why would we deprecate the option that developers overwhelmingly choose to use?<br class="">
Is it “for their own good”? Let’s remember that most people resent being told to do something “for their own good”.<br class="">
<br class="">
There’s something inside most people’s brains that wants to make other people do something “for their own good”. I’d argue that this applies in spades to language designers. We want to make Swift even better than it already is (and I think that it’s already
pretty darn good). So it’s really tempting to have the compiler enforce doing the right thing.<br class="">
<br class="">
But we also want other developers to make a voluntary choice to use Swift, when they could just as easily stick with Objective C, C, Java, or whatever they are using right now. At least, I hope that’s what everyone on this list wants.<br class="">
<br class="">
Or do we want just Swift to be the cool language that those of us in the “in” club use, without necessarily wanting other people to join our exclusive little club? The answer to that question affects the discussion.<br class="">
<br class="">
Taras Zakharko suggests that Swift isn’t trying to appeal to everyone. Perhaps not, but I hope that it does. We are long overdue for a modern general purpose language that compiles to, and is interoperable with native code. I think that Swift is great enough
to be that language.<br class="">
<br class="">
If we have already made a particular choice, and we’re used to defending our choice as being the right one, it’s really hard for us to even imagine that we might have made a decision that doesn’t further our eventual goal. So, what’s the goal for Swift? Is
it to be the language that finally takes over from C’s popularity? Or is it to be a specialized niche language?<br class="">
<br class="">
The answer to that question affects the question of C-style For loops too, I suspect.<br class="">
<br class="">
Andrew Bennett illustrated a neat way to generate an iterator using “defer”. It’s quite nice, but I would argue that it doesn’t jump out as being the perfect solution that’s so insanely great that people will give up C so that they can use it.<br class="">
<br class="">
Taras Zakharko kindly pointed out that the Swift compiler implements enumerable collections as lazy iterators. I was aware of that (and the way it’s done is pretty cool), but it seems dangerous to me to assume that the compiler will always be smart enough
to avoid creating large enumerable collections. I think that looping is so common that it deserves its own flexible syntax.<br class="">
<br class="">
Xiaodi Wu says "It seemed a little irksome at first to refactor, but that was about it”. I think it’s fair to say that the folks on this mailing list represent a more technically astute segment of the computing community. Several people have mentioned having
to refactor their code. But if other options are really better, why didn’t each of us use them right away, instead of reaching for the familiar For loop?<br class="">
<br class="">
My thought is that it’s better to attract than to dictate. How many potential Swift users are there? I think that the answer could be “an awful lot”.<br class="">
<br class="">
Even if the C-style For loop doesn’t appeal to everyone, I don’t see is as being so terrible that it needs to be removed in order to mitigate its horrible effects. I don’t see the Java community clambering for it’s removal. Nor do I see C# users being advised
to avoid the For loop because of it’s horrible dangers. But maybe I’m missing something. The older I get, the more I realize I don’t know. Are there horrible dangers associated with its use that I’m unaware of?<br class="">
<br class="">
So, I’d ask “why is it so terrible that we’re going to remove it, even though it presents an obstacle to developers coming over to Swift?” Maybe there’s a really good answer to that, but if there is, I haven’t seen it in the discussion thus far. Did I miss
something really important in the 0007 discussion?<br class="">
<br class="">
Thanks,<br class="">
Dr. J. Heerema</blockquote>
</div>
</div>
</span>
</div>
</div></blockquote></div><br class=""></div></div></body></html>