, Steve Pavlina, 2000-06-13, that I found very interesting. It has a lot of meat (real useful content) to it, which was unexpected given the title.DKF - Good page, and I agree with it 100% both as a software engineer and as a Tcl developer. Now, what other Wiki pages can we link this one in with?
KPV - Interesting page but I disagree. Software development has many aspects including new features, bug fixes, refactoring, etc. Unfortunately you only have a limited amount of resources and time, and you have to balance all those factors. As Joel Spolsky writes in the excellent essay, Hard-assed Bug Fixin'
- Fixing bugs is only important when the value of having the bug fixed exceeds the cost of fixing it.
CAU thinks there is a balance to be struck. Not fixing the bug because it costs too much to do so now (time is also an expense) has to be weighed against the impact of having to fix it later, which I believe is the emphasis behind the article on Zero-Defect Software Development.If you're interested in testing, check out what Kent Beck has to say on the subject - very enlightening and amusing: [1]
CL makes an effort to relate this convincingly to Tcl, and comes up with this: Tcl has an advantage (over, let's say, C) in ZDSD 'cause there's such a short distance between idea and executable.
TV: It brings to my memory the term correctness by construction, which one could apply to function (de-) composition techniques. It breaks down at the first loop, then you'd have to do protocol analysis, maybe process algebra for verification/construction.Of course the major advantages for errorless development with tcl / tk are that memory management is absent and as far as internal (near ?) perfect, pointer dealings can be limited to elements from well-formed sets, and the user interface should be faultless at least at the level of the elements one applies. Major advantages.I guess timing is harder.GPS: Tcl does have memory management issues. Global arrays are not collected, and things like http::cleanup have to be called or references need to be counted to clean up Tcl structures. In particular due to the lack of a garbage-collector we have memory faults and leaks that are too common in the C code. There are ways around this. The Boehm Garbage Collector could possibly be used in future Tcl versions; which would eliminate most issues with leaks (there are already some languages using it).JE: The Boehm collector wouldn't help with Tcl-level leaks. If you don't unset a global (delete a namespace, destroy a widget, remove a command), then the memory it occupies is still reachable from an internal hash table and the garbage collector won't collect it. And there really aren't many leaks in the C code -- the maintainers are pretty meticulous about proper memory management.TV I'm not sure what you mean by memory faults, which is an important issue. I have no problem with globals being around as long as I do not on purpose unset them, that what they are globals for, so that is not a fault imo, but if they would eat more memory by getting set and reset to new values, outside the bounds of in that process at any time not use more than twice plus a bit the maximum reasonable memory space required to store the content, than I don't see that as a fault.The idea of garbage collection I guess would be to have all chucks of malloc-ed or 'object defined' memory deleted as soon as no 'official' pointer or otherwise references to them are present anymore, which is a programming error in my opinion, and is a 'fault': you should deallocate memory you dereference, and I'd say that is normally speaking always possible. I didn't look into the tcl code much, but I guess it by and large should not contain such error.I you want to delete global vars like in the http library, which is written in tcl and can therefore not be blamed for 'errors' in the tcl core, I'd think it may not be a language error: you have to close files you open, too. I know that in tclhttpd descriptors of kept alive connection linger around as globals, which is not realy a tcl error, and not necessarily a tclhttpd error, though it would be neater to limit the time which they stay around.It leaves me with the question if tcl/tk core code 'leaks' memory: running tclhttpd for weeks on a row doesn't make me conclude it eats lots of memory, but I don't know, and indeed that would be an error.A whole page might be in order to see what all happens with the unneat and basically unpaged stack and heap(s) of a tcl executable on for instance windows, and even linux (hopefully not unix), lets say the core allocates a 1000 pieces or 99999 byte variables, and then the tcl program runs such that effectively, each such variable content is reduced to 66666 bytes, does that mean that we we can subsequently assign 1000 vars of 33333 bytes a piece to end up with the same heap (program related, malloced) memory size, roughly?DKF: Tcl has very few memory-leak faults. Maybe none, though that's probably not actually true. Not that this guarantees anything about Tcl scripts though. It is quite possible to write scripts that leak in an effective sense (the memory would be theoretically recoverable, but the process size would still grow unboundedly...)Tk is known not to be of the same quality. We're trying to make it better, but Tk's very asynchronous which makes it hard to work our when to really deallocate things...
