freenode/#clim - IRC Chatlog
Search
3:58:36
beach
I recently saw some very real evidence of the result of Kahneman as reported in his book "Thinking, fast and slow", i.e. that the fast module is lousy with things like orders of magnitude and statistics, and the slow module is lazy so it tends to believe the fast module. The evidence I saw makes me very convinced that a large number of wrong decisions are made with respect to software development.
3:58:44
beach
In this case, I mentioned that I plan to track source information in SICL by keeping a string containing the text of each source file in memory with the code, and I got a pretty violent reaction.
3:58:46
beach
After some verification, it turns out that the entire source code for the Lisp machine is around 50MB, which represents 20 cents of RAM. For the SICL source code, it's 6.4MB or around 3 cents. The fast module had obviously estimated several orders of magnitude more and the fast module didn't bother to check.
4:01:12
beach
The advantages of keeping the source code with the executable code is of course that, even if the source file was not delivered or installed, or if it was modified a posteriori, then I can still have precise error reporting with respect to source location.
4:03:16
beach
I am intimately convinced that many wrong decisions about what optimizations to implement are based on a hunch delivered by the fast module, and that if the slow module had bothered to check, it might turn out that the potential gain is very small and that it would be better to spend that energy on more profitable work.
4:05:39
beach
Hmm, I might get a chapter in my book about the sorry state of the software industry out of this kind of material.
4:20:24
nyef
Note that storing the source code with the running image is one short step from treating the version of the source code in the image as the master copy, which we already discussed as being a Bad Idea.
4:20:59
nyef
(I'm not saying "don't store the source code with the running image", I'm saying "here's a line that almost certainly shouldn't be crossed".)
4:21:23
beach
It will be stored with each function, so that it will be the true version that the executable code was compiled from. That's the only usage.
4:22:53
beach
When EDIT is called, the in-memory copy should not be modified. Instead, the file should be looked for, compared to what is in memory (and warnings issued if they are not the same), and then the file should be loaded into an editor buffer.
4:24:50
beach
And this scenario should be respected for a LispOS as well. There are no "files" there perhaps, but there is an editable object for the source and there is this read-only copy of it that gets associated with the executable code.
4:25:52
nyef
I'm not convinced about "no files", but I'm happy to entertain "files are not necessarily bags of bytes".
4:26:01
beach
So storing the source code with the executable is just a very cheap way of improving the debugging experience.
4:27:32
nyef
There's still a scenario where total "memory" usage is an important consideration. And that's low-bandwidth data transfer.
4:29:13
beach
Well, my main point with this rant was not about memory usage, but about how the fast module can get it wrong by several orders of magnitude. The ultimate decision about memory usage depends on situations like the ones you mentioned, and whether the creator of the software cares about such situations.