[swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Ted F.A. van Gaalen]

> On 08.07.2016, at 00:33, Chris Lattner <clattner at apple.com> wrote:
> 
> On Jul 7, 2016, at 7:46 AM, Karl <razielim at gmail.com> wrote:
>> Not only that, but we have compiler fix-its. When there are renaming changes or argument-label changes, I just filter down my Xcode error list, click each one, give it a quick eyeball and hit “enter”. I don’t know of other languages that have had such good migration infrastructure for existing code. I don’t know how Linux users get the benefit of these fixits, though. 
> 
> Helpful hint for folks moving from Xcode 8.0 beta 1 to beta 2 (and beyond): when you open your project in a new beta, make sure to go to "Edit -> Convert -> To Modern Swift Syntax…”, which will help move you up by automatically applying the migration fixits that correspond to the changes in the new beta.
> 
> -Chris
> 
Hi Chris, sorry for the delayed response.

In many cases Swift converters/ migration tools are certainly helpful,
however they work mostly scanning on a statement-by-statement basis, 
having "not enough AI” to grasp and process the context 
e.g. for a cluster of source lines...

So, e.g. if one has programmed a function with its logic heavily based
on deprecating or removed Swift language elements, one still has to edit and
retest that code, which mostly consumes lots of time. Additionally, 
in many cases - albeit somewhat reduced by good structured design -
these changes influences also other parts of the application. 
(but we all know that of course)


imho and after releasing Swift 3.0: 
               ===================

Existing language elements should never be removed,
    (even if they are frowned upon, which occasionally is caused
     by aspects of subjective opinion, lack of experience and premature vague statistics, we’re human aren’t we?)
and even if much better newer solutions are available. 

New language elements should be supplements, standing on their own,
with the purpose of extending Swift, not as changes of existing code, 
thus leaving the older equivalents intact as not to break older source code. 

         (it would then to be expected that,
          if better alternatives are made available
         these would of course be preferred,
         causing the older alternatives to be forgotten 
         after some time. Like the classical for-loop for instance.
         but, they’re still there to stay compatible with older source code) 

-Even renaming language elements makes revisiting
and editing often large amounts of source code necessary.

Yes, I know this can be quite a challenge, nevertheless
it is necessary, i think. 

In a (often unforgiving and stressed) production-environment
we used to write code in a “fire and forget” modus,
that is once written and tested it should run forever! 

There simply is no time for revisiting. For instance, if one
would have to re-edit an old source to make minor
changes, then it wouldn’t be enough to just correct
this perhaps minor error, as one would have to edit
many source lines because the compiler won’t accept
language elements used some time ago and
now rendered obsolete.

Unless you allow to compile conditionally for each and every version
of the language. But conditional compiling creates a
mess, and makes source code hard to maintain.

Changing language elements or, even worse, removing them
makes it a tedious and very costly necessity to revisit and 
re-edit all previously written source code, not to mention
that after that, all application/libraries involved need to be 
tested again! 

If it is just a trivial application, then this still could be done
without too much effort, however, in more complex cases
this could result in a real nightmare, consuming lots of time and money.

If i am not mistaken, the word “deprecated” originated in the Java
world. There the questionable culture of rücksichtslos throwing
things away started, I guess. Trendy perhaps? 
In this culture, tons of Java code needs to be revised, 
tested and re-released almost yearly because of that.

I think we should not make the same mistake.

Changing things all the time would certainly diminish Swift’s 
popularity by professional developers.

In all these years as a programmer my general experience is,
that  improvements in programming languages are supplemental*
not changes or removal from existing language elements. 

As perhaps misunderstood (from my previous writing) by some of us:
Of course I am not in favor of stopping development of Swift. 
but imho as described above, changes should be supplemental
and not replacing existing language elements or removing them. 

In this perspective “Freezing Swift” is meant here to keep all 
new supplements in beta, yes, for a prolonged time, 2 years or so. 
In that time Swift will have many more users, that no doubt, will 
come with valuable feedback allowing to 
improve the language even better.  

Please note that all the writing and considerations above concerns the
time AFTER the release of Swift 3.0.

I see a lot of good ideas and enthusiasm here, but
i might perhaps assume that many here didn’t work in a tight an
tense production environment?   

At least please try to imagine what it would be 
if you would have to maintain source code that:
  -was written a few (ten?) years ago
  -cryptic sources worked on through by many people, of talented and often rookies,
    hired and fired and hired again.
  -a lot of times you wouldn’t have time to solve problems decently, or
   rewrite it, it just has to be patchwork.

I had to work many years like that and some projects almost drove crazy.
burn outs and so. 
could tell you things that make you cry.. (but hey also positive things too) 

I’d say one should pay more attention to these aspects.

Also, Swift has the very powerful feature to write one’s own
extensions, protocols and forms of inheritance.
This imho reduces the need to chance the language.

Thanks for reading.
Kind Regards
Ted







@ Karl :

Yes, it was blown a bit out of proportion, I hope the
above has  nuanced it a bit. 


@Charlie Monroe:

Your assumption:

> Both are examples of languages that do not have a lot of sytax/features/complexity. Such languages are more easily production-ready from day 1.

Forget it :o)
On the contrary, both languages PL/1 and Cobol are much more complex than Swift.
Take a look at the programming manuals, language specs. 

Kind Regards
Ted