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 <[email protected]> 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 > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
