3 ms·

> "The language is restricted in various ways to prevent error that can result in an unrestricted environment." Sadly, this is not true for us programmers. By

> "The language is restricted in various ways to prevent error that can result in an unrestricted environment." Sadly, this is not true for us programmers. By and at large, we have preferred to devise mechanisms (such as exceptions and contracts) that protect us from the consequences of our mistakes, rather than attacking the root cause of these mistakes - our failure to enforce pre- and postconditions using static techniques. And this situation is not going to improve as long as we stick to a limited vision that embraces integers, strings, lists and trees, but not equality of terms as types.

taeric 13y ago
I'm sorry, but this has nothing to do with "us programmers." Humans, by and large, don't have a good way to tell a desired story with all of the branch points accounted for. This is why cookbooks don't have recipes with "if you cooked it too long here, switch to this recipe..." Hell, this goes so far as to how we currently give people directions to cross a state. Consider http://goo.gl/maps/4F89Z http://goo.gl/maps/4F89Z This clearly doesn't work because there is not a car that can do that trip completely non-stop (well, that I know of). Yet, it would be silly to even try and account for all of the random stops that a person making that trip would want to do. How is this the fault of "embracing integers, strings, lists and trees?" Having looked over all of the various ways that we give directions to kids lately, I'm becoming more and more convinced that the higher theories of programming are missing something (for a great presentation on this idea, see [1]). Look at how music is written. Look at how lego directions are written. Ikea directions. Shampoo directions. Cooking recipes. All of these are relatively successful methods for communicating often complicated sets of directions. None of them necessarily encode things to the level of detail that our programs require. Are you concerned that all of my examples are not necessarily life and death detail oriented? See the blueprints of rockets. Sail boat designs from ancient times. Heck, sailing routes. If anything, I would say that our programs should, instead of offering fancy ways to escape the consequences, programs should offer ways to "get back on the desired path" of what was supposed to be accomplished. The canonical "FileNotFound?" Don't put my program somewhere where I have to somehow set things back up to try again. Resume right here once the file has been found. (Sadly, I don't have any good thoughts on this. Just late night ramblings.) [1] http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...

taeric 13y ago

I'm sorry, but this has nothing to do with "us programmers." Humans, by and large, don't have a good way to tell a desired story with all of the branch points accounted for. This is why cookbooks don't have recipes with "if you cooked it too long here, switch to this recipe..." Hell, this goes so far as to how we currently give people directions to cross a state. Consider http://goo.gl/maps/4F89Z http://goo.gl/maps/4F89Z This clearly doesn't work because there is not a car that can do that trip completely non-stop (well, that I know of). Yet, it would be silly to even try and account for all of the random stops that a person making that trip would want to do. How is this the fault of "embracing integers, strings, lists and trees?" Having looked over all of the various ways that we give directions to kids lately, I'm becoming more and more convinced that the higher theories of programming are missing something (for a great presentation on this idea, see [1]). Look at how music is written. Look at how lego directions are written. Ikea directions. Shampoo directions. Cooking recipes. All of these are relatively successful methods for communicating often complicated sets of directions. None of them necessarily encode things to the level of detail that our programs require. Are you concerned that all of my examples are not necessarily life and death detail oriented? See the blueprints of rockets. Sail boat designs from ancient times. Heck, sailing routes. If anything, I would say that our programs should, instead of offering fancy ways to escape the consequences, programs should offer ways to "get back on the desired path" of what was supposed to be accomplished. The canonical "FileNotFound?" Don't put my program somewhere where I have to somehow set things back up to try again. Resume right here once the file has been found. (Sadly, I don't have any good thoughts on this. Just late night ramblings.) [1] http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...