4 ms·
Eh, this isn't new and innovative. For more information, check out SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3 http://mitpres
by bricestacey 17y ago
Eh, this isn't new and innovative. For more information, check out SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html...
Also, since the logic is stored in a lookup table, these can always be changed on the fly.
- DrJokepu 17y agoThat's exactly what I was talking about. That's why I put these word within quotation marks. Maybe it's just me but I don't really like the idea of changing code on the fly. It (a) makes code a lot harder to prove for correctness (b) a lot harder to debug. There are cases when it is a good idea in some very specific algorithms but in general development, I think self modifying code is a big no-no.
- derefr 17y agoWhat about cases where you basically want the user to specify the condition at runtime, with what amounts to a Turing-complete language for writing those conditions? In the Tivo example, pretend you wanted users to be able to go up to the device and say "only record shows where one of the lexicographical permutations of the length in minutes is a prime number." The only way to avoid it is not to avoid it: to create a user-extension language with its own compiler, and a VM embedded into the program.
- DrJokepu 17y agoOh yes allowing scripting is often an excellent feature, but I wouldn't consider a scripting interface "changing code at runtime". The boundaries of the application and the scripting environment are clearly defined most of the time. Scripting is more like receiving automated control input. Of course the JIT of the scripting language might have self modifying parts in it but that's not the point.