I did not want to take this discussion further , because I dont like to annoy people . But some of the points made here are presented as facts and I don't like that.
> Chris, in discussions about "compatibility" , people always missing to > mention one little thing: > users can always choose to not upgrade their projects and keep using > older releases. I will mention another thing. Freedom is an illusion. In the end you are always bound by limitations and your own personal needs. Especially that nasty little thing that is called "dependecies". When a library depends on an another , not upgrading can be not even option. This is why I separate braking compatibility in the language side and braking compatibility in the library side. I am perfectly ok with libraries that brake compatibility , why ? Because you can ignore a library and just move to something that fit your needs better. But with language is a lot more difficult to do that usually because the libraries that you are going to use are going to depend on a specific language version. > Now, don't you think that it would be strange if new release of system > will function exactly as old one, so users can run their project(s) > without changing even single line of code? > This is possible only if new system(s) should be same thing but with > extra functionality. No I don't find it strange , actually its not even rare, its common practice for most libraries out there not to brake backward compatibility. > And that will mean that development model would be "never change > anything, but add things on top".. Nope thats simple is not true, you are allowed to change everything except the name of the methods and classes. Which is a small part of the code. And you are also allowed to add as much new stuff as you want as long as its optional. This means that there is nothing stopping a backward compatible library new version to be better than a non backward compatible library new version. > The software has to evolve, and evolution means changes. And so, if > you wanna benefit from system improvements, you'll have to make your > hands dirty and do some changes in your code to fit with new system. > This is a price you pay for having better system. And there's no > escape from that. I don't know why you believe that backward compatible means no progress and non backward compatible means progress. This is simply not true from my experience. I have used a lot of backward compatible libraries and they keep getting better and better. The only piece of software that I used that has gone through the biggest rewrite ever, is blender and I have to admit that the rewrite greatly benefit blender. But blender had a lot of issues and it was clear that much of its basic functionality was deeply flawed and desperately needed a refresh in design. Thats not always the case with software. Some designs have stood the test of time so braking compatibility makes no sense. If you want to keep improving that specific library you can keep doing it. I can give you an example if you want, VCL , it's Delphi's own library. We talking here about a massive library nothing like smalltalk libraries. Has been backward compatible since 1996 that I have first used Delphi and its still is probably the best library I have used together with the other Delphi libraries. The guy behind Delphi knew exactly what a good design is and knew how to make real R.A.D tools which is pretty much the goal of smalltalk itself. The result was that his designs were so successful and liked that he was snatched from Mircrosoft to create .NET and C#. Suffice to say .NET clone most of the designs of Delphi. But even till this day Delphi is highly popular (not as popular as it was in the past) and highly regarded piece of software. But as I said , I am not against braking backward compatibility , in many cases its the best thing to do. But if braking backward compatibility is always your first option then I fear you are going to have the exact same problems blender has with addons developers. And certainly users wont love you, I can guarantee you that not in the short run or the long run. Another thing I must state here , is that as a user did not choose pharo over squeak because it brakes compatibility. I am saying that because I fear I am not the only one to have done so. Because its a dangerous conclusion for one to make that just because someone prefers pharo to squeak because for him it has been more stable and because more libraries are actively developed for it, that is implied he is a big fan of braking compatibility. I also respect the fact that you as developers decided to make "braking compatibility" as a central value of pharo. Its your project you have the right to do whatever you want with it. And I am not even saying its a wrong choice. I only hope for me and others that I dont end up hitting my head against the wall as I have done with the blender api. I can bare a bad design and even get used to it, but something that brakes my code in every single version is simply.... a pain in the a@@ And staying with old versions is not a viable solution for me. I will probably end up choosing squeak or whatever can make my life happy and fun again. On 14 December 2012 23:42, Chris Muller <[email protected]> wrote: >> - the consensus is that FileSystem is a nice API >> - the consensus is that FileDirectory is/was ugly > > Hence, you echo my original statement from the other thread. I wrote: > >>> ... While someone in the Pharo >>> community said FileSystem over FileDirectory is "huge", I see it as an >>> incremental API change, and close to being a matter of preference. > >> And you don't want to switch to it ? >> Or you want to keep the old API and not force the switch on users ? > > Both. Because, while FileSystem is a cleaner design, the question > posed was whether it is _worth_ breaking so many legacy packages and > the promise of O.T. for "a nice API". That's when dramatic attempts > to intensify the contrast between the two came out but with no > concrete examples we arrived full-circle back to the original > question. > > An acceptable compromise for me for putting it Squeak would be a > FileDirectory wrapper that can pass its own test suite, which is > precisely what Pharo did! > -- Best regards, Igor Stasenko.
