[swift-evolution] Avoiding back breaking changes and removals.

Tue Jul 12 12:57:42 CDT 2016

Hi Jean-Denis

please look at my response in-line further down.

I am also writing this text because I think
that the implications of back breaking chances
are severely underestimated.

Again, the scope of my writing concerns the situation after Swift 3.0

Veuillez recevoir, Monsieur, nos salutations distinguées.

Ted

> On 07.07.2016, at 14:12, Jean-Denis Muys <jdmuys at gmail.com> wrote:
> 
> Ted,
> 
> I basically disagree 100% with everything you wrote.
Ok, it was a bit supercharged as in effect, I meant
only source breaking changes.

However also my recommendation to move a bit slower 
for a year or two so that people (not only the Swift-evolution participants)
really have started using Swift is a consideration… to get
more matured feedback, which then can play an important
role in improving Swift further. 

> I will not got into much details, but for me, technology that doesn’t evolve is dead technology.

I agree with this of course! 

 The subject title I gave this thread: 
> "Seriously! Freeze Swift For Two Years	After Release 3.0 !”

and also what I wrote was a bit over-dramatic. That is a bit my nature…:o) sorry. 
Now  it has a more appropriate subject title as you can see above.

What I (but who am I?) would prefer is:

All improvements and changes should be supplemental only.
thus leaving what is already there intact.

 ===================================================================
 This Would 100%  Guarantee That  Everything Ever Built, Never Needs To Be Changed.
 ===================================================================

(that is, within the scope and context of the programming language itself, of course) 

This is certainly feasible and proven: there are a number of programming languages that
adhere to this basic rule. This is e.g. the case with the classical languages Cobol and PL/1 for
C, C++ for  example.

> 
> Moreover, your main argument about large code bases, is not a good one: we now have migration tools that work quite well. They could be made even better, with some investment, that most (I think) would rather see invested in the leading edge.

As I wrote before, I think that in many cases 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…

Imho, it is nearly impossible to write a migration tool that catches everything
and automatically converts flawlessly.
Making such a migrator would probably use as much or even more effort
as making the Swift compiler itself.

I have worked for many years in IT-environments with extremely large
and often ancient code bases (Mainframe, banks insurance companies etc.)

In these environments,- even without source migration - 
it is extremely difficult to apply changes to existing software, thousands of
sources scattered al over the place: a myriad of chaotic intertwined sub systems, 
often badly connected via middle ware, chaotic file systems etc.  Yes, from time to time
change managers/firms are hired, however,  in many cases this makes it even worse.
Note that this is not a worst case scenario but the average large systems scenario.

> Aversion to change is everywhere. It’s deeply engrained in us human beings.

Yes, very true, albeit that it is a very understandable feature of human intuition
as changes are risky in many cases. This does not imply that change
should be avoided at all times of course! Apparently I gave this impression 
unintentionally in my previous writing. 

Especially in IT , the reluctancy to change is very plausible if changes bring 
severe risk of malfunctioning systems. For example changes to large bank’s 
accounting systems literally consisting of thousands of programs, modules
and files and a few different databases simultaneously.. These systems are
extremely fragile.

When changes applied go wrong, it cause severe financial damage. 
It happens many times as it is very hard to foresee the impact 
and side-efects these changes might have in 
large (and mostly hybrid) systems.

So imagine something so trivial as changing the Cobol assignment statement
"MOVE A TO B.”  to  "COPY A INTO B."
(which btw would have been more correct, because basically that is what it does)

Even such a small change  can have an enormous impact. On top of that,
as changes to sources also need a conversion cycle when there is backwards 
breaking the situation will be extremely difficult. 
The example here is just a trivial case.  

A hypothetic but realistic example:

Swift is intended as a general purpose language, so, what prevents
us from writing a complete accounting system with Swift? 

Let’s assume a company decides to (re)built its complete company-wide 
accounting system using Swift as its main programming language. 
About 40 Swift programmers are hired, they manage
to built this accounting system in even less that a year. 
(which might be feasible because Swift is flexible and powerful) 

The codebase for this hypothetic accounting system
 (compared with codebases in say Java and/or Cobol)
could  contain (among other software, database etc.) 
more than thousand Swift source files.
This is a realistic estimation.  

If, say, a year after completing this accounting system source compatibility
breaks, they are in real trouble.  (as with Java sometimes)
No, there is no time and  budget to rewrite and test! say, about 700 source files.
This is not an exaggeration. 

Ergo: 
If it can, the project management will only accept Swift
 (or for that matter any other language/system ) 
if and only if 
there is an 100% guarantee that future changes 
of the programming language 
will not break existing code.

Chris has emphasized to me the following Swift goal / intention:

> "The primary goal of this release is to solidify and mature the Swift language and development experience.
>  While source breaking changes to the language have been the norm for Swift 1 through 3, 
> we would like the Swift 3.x (and Swift 4+) languages to be as 
> source compatible with Swift 3.0 as reasonably possible.”

Well, that is positive, but imho not good enough.
There should be no source breaking changes at all.

> That’s why consultant make a living selling change management.
Definitely not a job for me… :o)   

> I have seen people complain a lot about Apple releasing new versions of iOS for example. I have seen developers complain that Apple releases new versions of Xcode too frequently.
Yes, people often complain and it is true imho that releases come a bit to often these days. 
Oh the other hand, there are many large iOS  apps out there. 

> I was even not too long ago in a position to do a web development job for a customer who wanted to support Internet Explorer 6. I have very little sympathy for such plights.
It really depends on the situation: 
I know of the case of of a large German company where
there was a very large system (and probably still is) based on IE 6,
 but sometimes there is no money and/or time to upgrade it. 
Have you read about air traffic systems? 
There is a lot of “old” software, mature and stable, 
in many businesses, functioning very well and if it were
not from pressure from “outside” and evaporating OS s 
they would still be quite happy.
Yes, missing out on progress of course, 
but in some businesses this is irrelevant.

> If you don’t want to maintain your Swift 2 code, don’t. But don’t prevent the rest of us from doing it, despite the efforts required.
No, I don’t want to remain with older Swift versions, but move on with newest versions. 
These however, should flawlessly compile everything written in older versions.
> 
> I applaud the way the Swift team is handling those breaking changes, piling them up as early as possible, postponing additive changes to post 3.0.
> This is the way to minimise the efforts as much as possible.
I subscribe to that.

> I hope that even then, source-breaking changes will continue to happen when they make sense.
I certainly hope not. 

> I am looking forward to a language that will get constantly better at enabling me to evolve my code in the most productive way.
Yes, me too!

> If my source code breaks, that is a very small price to pay.

Would you still have this opinion if you (or your team)
after two years or so would have to edit hundreds of source files manually?
(because the source breaking change cannot be automatically converted?)

For example, after the removal of the classical for-loop with floats like this one:

        for var x:Float = -60;    x < 60;    x += w * 1.2
        {
            for var y:Float = -30;    y < 60;    y += h * 1.2
            {
               let pos = SCNVector3(x: x,   y: y,   z: z)

                let tile = TGStaticTile(pos: pos,
                                w:  CGFloat(w), h: CGFloat(h), l: CGFloat(l),
                                color: UIColor.randomColor(), naam: "Tile\(tiles.count + 1)")

                tiles.append(tile)
           }
	}

I have more that a few of these in my AppleTV app under construction
which I all have to rewire manually when Swift 3.0 arrives,
because the migrator can not do it. 

AFAIK, there is no automatic source conversion possible
in the above example.
(Also, there is no alternative in Swift yet for classical for-loops.
(I brought this forward extensively a few months ago,
but no one seems to care. I still can write a proposal
to reinstate the classical for-loop, but I guess it would be rejected))  

N.B. an example: Some time ago, I was in favor to remove
variadic parameters from functions. This contradicts
the way I think now about removing language elements
I now think it should not be removed: 
it is still there then, but one doesn’t need to use it.

met vriendelijke groeten
Ted
https://www.tedvg.com
https://www.ravelnotes.com
https://soundcloud.com/ted-van-gaalen
https://tedvg.deviantart.com

> 
> Jean-Denis
> 