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

[Ted F.A. van Gaalen]

Hi John,

well, I certainly don’t want to return working with C or C++
(I am still recovering from working on C only project on OS/2 
back in 2002 :o) after this little nightmare I always tried 
to avoid as much as possible working on C/C++ 
and also Javascript projects...

Pascal was/is? ok too, I learned OOP with Turbo Pascal 5.5 
in 1989-90. (it should have been Smalltalk but (private) computers
were not fast enough back then) 

If I was given the choice of using either C/C++ or OOP Pascal, 
I would choose Pascal because due to its rigid structure it catches 
a lot of programming errors at compile time instead of run time. 

This is a very important aspect of Swift: 
that it catches a lot of mistakes at compile time!  
I am very grateful for that because it saves me
a lot of trouble at run time, let alone the embarrassment 
of having to solve bugs in already distributed applications 
(of course, you can’t prevent it all) 
Unfortunately this is very hard with “totally free” languages 
like C and C++ are. To me it is almost that C/C++ are a kind 
of super-assemblers and therefore (still?) good for making 
low-level system software. There is an old, albeit ia bit macabre, 
saying that “C and C++ provides all the rope to hang yourself”.. 
However, In the digital domain, for most of us I’d say 
this is very true.

It is also therefore that Pascal has a more fool-proof
for-loop 

  for < variable-name > := < initial_value > to [down to] < final_value >   
  do
     /* statements */ 
  end

...or the 1964  PL/1 variant which has a variable increment/decrement value

   do i = 10 to 5 by -1;            /* "by 1" is the default if not specified */
       /*statements*/;
     end;

The variant I am suggesting for Swift is more or less based
on these Pascal and PL/1 implementations because they are safe, 
natural and readable, even for beginners.
Because Swift does not offer easy-to-work-with similar variants
it is regretful that the Swift: 
    for  initialization;    condition;  increment/decrement

has been removed as written in Proposal nr. 0007, even
before offering a satisfying alternative. 
I still don’t understand why the Swift core team has accepted 
such a proposal,  largely based not on facts
and adequate research, but mostly on very subjective criteria.
Alas, but I have already described my opinion about 
this proposal 0007 in a previous post. 

However to return to the overall topic here: 
Pascal, made by Niklaus Wirth offered imho a 
“reasonable amount” of protecting the programmer 
against one’s self, so that one does not encounter
pitfalls again and again, which does not only happen
with beginning programmers but also with 
experienced digitally active ladies and gentlemen too.

Later on, Niklaus Wirth created Modula-2. 
(and after that also Modula-3) 
If one wants to see really good scope handling then 
take a look how this is implemented in Modula-2 here:
https://en.wikipedia.org/wiki/Modula-2
I think this could be a good base for the modularity
in Swift as well. 

Back then in ca. 1991, I bought a Modula-2 language system
from TDI  for my Atari 520 ST, although I found programming
with Modula-2 on many occasions a bit too restrictive.  
However, I quickly noticed that my apps made with Modula-2
were more stable with very little run time bugs or memory 
runaways.. 

So some protectionism is a good thing, 
this is what Swift offers too, which I really appreciate.
but to what extent does this need to be enforced?
How far does one go? 
Imho, that is exactly what we should discuss.
It is about the range between too rigidly enforcing restrictions
and making a language “totally free” 
Both have it’s pros and cons. 
The art then is, to find the silver path in between
these extremities. A dogmatic approach
(on either side) is not really very helpful.

TedvG


 



 

> On 05.04.2016, at 03:30, John Heerema <jheerema at ucalgary.ca> wrote:
> 
> Thanks! I enjoyed reading your post today.
> 
> I don’t see having two ways to do something as a weakness, but a strength.
> Again, that’s why weird-old English won out over Esperanto.
> And why messy-old C won out over Pascal and Modula-2 (and, if we’re not careful, Swift).
> 
> Regards,
> John
> 
> From: "Ted F.A. van Gaalen" <tedvgiosdev at gmail.com <mailto:tedvgiosdev at gmail.com>>
> Date: Monday, April 4, 2016 at 1:40 PM
> To: John Heerema <jheerema at ucalgary.ca <mailto:jheerema at ucalgary.ca>>
> Cc: swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>, Taras Zakharko <taras.zakharko at uzh.ch <mailto:taras.zakharko at uzh.ch>>
> Subject: Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations
> 
> Hello John
> I subscribe completely to this point(s) of view!
> TedvG
> 
> 
> 
>> Date: Sun, 3 Apr 2016 19:25:09 +0000
>> From: John Heerema <jheerema at ucalgary.ca <mailto:jheerema at ucalgary.ca>>
>> To: "swift-evolution at swift.org <mailto:swift-evolution at swift.org>" <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>> Subject: Re: [swift-evolution] Revisiting 0004,0007 etc. - Swift
>> deprecations
>> Message-ID: <D326CA33.B1738%jheerema at ucalgary.ca <mailto:jheerema at ucalgary.ca>>
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> Thanks to all those who thoughtfully responded to this post! The folks who responded provided kind thoughts and advice.
>> 
>> Ross O’Brian asked if I was familiar with the original discussion for 0004 and 0007.
>> 
>> 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.
>> 
>> 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.
>> 
>> Let’s take proposal 0004 – to deprecate the ++ and — operators.
>> 
>> 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.
>> 
>> On the human side, what do the human being who write code actually do?
>> Human beings notoriously do not act in the way we think they “should”.
>> 
>> Lots of languages, like C, C++, C#, Objective C, Java, etc., already have both the prefix and suffix versions of ++ and --.
>> 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:
>> a = a + 1
>> a += 1, or
>> a++
>> 
>> 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.
>> 
>> 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?
>> 
>> So, why would we deprecate the option that developers overwhelmingly choose to use?
>> Is it “for their own good”? Let’s remember that most people resent being told to do something “for their own good”.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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?
>> 
>> The answer to that question affects the question of C-style For loops too, I suspect.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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?
>> 
>> 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”.
>> 
>> 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?
>> 
>> 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?
>> 
>> Thanks,
>> Dr. J. Heerema

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