Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unfortunately, the fact that a system is not designed to be used at a nontrivial scale is no guarantee that it won't be used that way. For instance, there are a lot of Excel worksheets doing things I am sure the designers of Excel never expected Excel to have to do.


What's the solution to this problem? On one extreme end you can clearly state its intended use in documentation and allow undefined behavior, and on the other end you prevent the user from using the tool in any undefined way.

I'm generally positive about restricting undefined behavior at a lower level (syntax, undefined field accesses, etc), but at a higher level (writing large scale applications, using it outside of intended domains, etc) it's not very clear how and even if you should restrict unintended usage.

The more room you have for "undefined behavior" at a higher level, the more people can explore using a tool in various ways you never thought about. This can in turn be valuable feedback on possible directions to expand your tool in.


it's not undefined behaviour, rather it's trying to be helpful by coercing stuff where it can. Unless I'm missing something, it's perfectly defined.


I mean, Excel does have LET and LAMBDA now...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: