3 ms·

We already see this in culture, in business and other public activities, even religion. The language is restricted in various ways to prevent error that can re

We already see this in culture, in business and other public activities, even religion. The language is restricted in various ways to prevent error that can result in an unrestricted environment. Unfortunately, this leads to compartmentalization, which can hide rot and bloat of various flavors. I'm not exactly sure what the solution is, but if history is any indication, these linguistic systems are often considered foul-proof to the point that those managing them stop managing them, or hand off management to someone and forget about it, letting any issue outside the scope of the language become a cancer of sorts that eventually kills the host.

mathattack 13y ago
Interesting in that I was thinking in terms of Python versus C++, but it's also true in real world languages. One could argue that the precision of Latin helped preserve the message of Christianity through the ages, though I am not an expert on the matter. I do think it's reasonable to have technical environments where language choices are done for support and debugging purposes, with the highest powered tools only pulled out on occasion.
- AsymetricCom 13y ago
  Of course, Chomsky has many books on the subject.
catnaroek 13y ago
> "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...

mathattack 13y ago

Interesting in that I was thinking in terms of Python versus C++, but it's also true in real world languages. One could argue that the precision of Latin helped preserve the message of Christianity through the ages, though I am not an expert on the matter. I do think it's reasonable to have technical environments where language choices are done for support and debugging purposes, with the highest powered tools only pulled out on occasion.

AsymetricCom 13y ago
Of course, Chomsky has many books on the subject.

catnaroek 13y ago

> "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...