Comments on: The Accuracy of Future Predictions http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/ Fri, 03 May 2013 14:52:50 +0000 hourly 1 http://wordpress.org/?v=3.1.4 By: Lyman Hurd http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-4390 Lyman Hurd Wed, 20 Feb 2013 22:08:15 +0000 http://www.codesimplicity.com/?p=1022#comment-4390 By that criterion, Microsoft Visual C++ failed for quite a while. Only recently did it get into line with the iterator of a for loop having the scope of the loop it enclosed (i.e., the following was not legal in VC++ but is perfectly good ANSI): for (int i = 1; i < 10; i++) { // do something } for (int i = 1; i < 20; i++) { // do something else } In VC++ it used to complain that you were trying to define "i" twice in the same scope. By that criterion, Microsoft Visual C++ failed for quite a while. Only recently did it get into line with the iterator of a for loop having the scope of the loop it enclosed (i.e., the following was not legal in VC++ but is perfectly good ANSI):

for (int i = 1; i < 10; i++) {
// do something
}

for (int i = 1; i < 20; i++) {
// do something else
}

In VC++ it used to complain that you were trying to define "i" twice in the same scope.

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-3436 Max Kanat-Alexander Fri, 18 Jan 2013 07:03:34 +0000 http://www.codesimplicity.com/?p=1022#comment-3436 So you know, once upon a time, I wrote two blogs posts about almost this exact subject. (Backwards compatibility in general, but it's relevant to what you've said.) http://www.codesimplicity.com/post/ways-to-create-complexity-break-your-api/ http://www.codesimplicity.com/post/when-is-backwards-compatibility-not-worth-it/ In truth, I think that the level of backwards-compatibility that C has maintained is likely a weakness at this point. The more and more you nail down a piece of software, the more and more it will degrade over time by not being able to adjust itself or improve itself as time passes. You're certainly correct that backwards-compatibility is a boon to developers, and it should never be broken without reason. But as I try to get across in the two articles above, the ultimate decision should be a balance between simplicity for existing users and simplicity for future users. -Max So you know, once upon a time, I wrote two blogs posts about almost this exact subject. (Backwards compatibility in general, but it’s relevant to what you’ve said.)

http://www.codesimplicity.com/post/ways-to-create-complexity-break-your-api/

http://www.codesimplicity.com/post/when-is-backwards-compatibility-not-worth-it/

In truth, I think that the level of backwards-compatibility that C has maintained is likely a weakness at this point. The more and more you nail down a piece of software, the more and more it will degrade over time by not being able to adjust itself or improve itself as time passes. You’re certainly correct that backwards-compatibility is a boon to developers, and it should never be broken without reason. But as I try to get across in the two articles above, the ultimate decision should be a balance between simplicity for existing users and simplicity for future users.

-Max

]]> By: Nick Barnes http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-3417 Nick Barnes Mon, 14 Jan 2013 13:47:39 +0000 http://www.codesimplicity.com/?p=1022#comment-3417 Of course the Python 2 code will still work in Python 2, including 2.7.3. There are a few things in Python 2.0 that don't work in 2.7, but this isn't one of them. Python 3 is deliberately incompatible. I think that the culture of language implementors and designers has gone a little wrong since the 1980s - there used to be a very serious concern about backwards compatibility. For instance any C compiler worthy of the name had better compile "ANSI C" without any semantic changes. I write "ANSI C", technically ambiguous, because that is *still* the shorthand used by C programmers to mean ISO/IEC 9899:1990, which was basically settled in about 1987. C compilers mostly also do a fine job of "K&R C", vintage 1973, although there is more variation because the semantics were not so clearly nailed down. Ditto implementations for a number of other languages from the 1970s and 1980s (e.g. Common Lisp: the Lisp implementations I use are strictly compliant with the 1994 Common Lisp standard, which was the result of a convergent standards process begun in the mid 1980s). The implementations have moved on, and can *also* handle other languages (e.g. C11), but have not dropped or impaired in any way their support for languages defined more than 20 years ago. This is a huge strength that the implementors of languages such as Python should emulate. Of course the Python 2 code will still work in Python 2, including 2.7.3. There are a few things in Python 2.0 that don’t work in 2.7, but this isn’t one of them. Python 3 is deliberately incompatible.

I think that the culture of language implementors and designers has gone a little wrong since the 1980s – there used to be a very serious concern about backwards compatibility. For instance any C compiler worthy of the name had better compile “ANSI C” without any semantic changes. I write “ANSI C”, technically ambiguous, because that is *still* the shorthand used by C programmers to mean ISO/IEC 9899:1990, which was basically settled in about 1987. C compilers mostly also do a fine job of “K&R C”, vintage 1973, although there is more variation because the semantics were not so clearly nailed down. Ditto implementations for a number of other languages from the 1970s and 1980s (e.g. Common Lisp: the Lisp implementations I use are strictly compliant with the 1994 Common Lisp standard, which was the result of a convergent standards process begun in the mid 1980s). The implementations have moved on, and can *also* handle other languages (e.g. C11), but have not dropped or impaired in any way their support for languages defined more than 20 years ago. This is a huge strength that the implementors of languages such as Python should emulate.

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-3415 Max Kanat-Alexander Mon, 14 Jan 2013 07:45:00 +0000 http://www.codesimplicity.com/?p=1022#comment-3415 What you really end up with, when you try to do that, is a lot of extra complexity for a future that doesn't arrive, and a ton of work to now adapt it to the future that really did show up. What you really end up with, when you try to do that, is a lot of extra complexity for a future that doesn’t arrive, and a ton of work to now adapt it to the future that really did show up.

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-3414 Max Kanat-Alexander Mon, 14 Jan 2013 07:44:23 +0000 http://www.codesimplicity.com/?p=1022#comment-3414 Nope, that is impossible. The future is infinitely complex, and software cannot be. Attempts to do this are one of the primary causes of overly-complex, unmaintainable systems. Nope, that is impossible. The future is infinitely complex, and software cannot be. Attempts to do this are one of the primary causes of overly-complex, unmaintainable systems.

]]> By: Simon http://www.codesimplicity.com/post/the-accuracy-of-future-predictions/comment-page-1/#comment-3413 Simon Mon, 14 Jan 2013 07:42:47 +0000 http://www.codesimplicity.com/?p=1022#comment-3413 Well, you *could* spend a lot of effort on designing and implementing a system to adapt to any possible change of circumstances that might occur in the future. Which is probably the only possible way of making sure that such a change will never happen... :) Well, you *could* spend a lot of effort on designing and implementing a system to adapt to any possible change of circumstances that might occur in the future. Which is probably the only possible way of making sure that such a change will never happen… :)

]]>