Posted to tcl by gps at Mon Jun 08 16:28:13 GMT 2009view raw
- Below is some notation I use for representing what forms a thought.
- 1 like Tcl ->
- 1.1 community
- 1.1.1 most of the community is helpful and friendly
- 1.1.1.1 why does this matter?
- 1.1.1.1.1 those that are helpful encourage sharing of ideas, and we help each other improve
- 1.1.1.1.2 it tends to lead to fewer volatile feelings
- 1.2 general ease of use
- 1.2.1 this may be based on my experience, and knowledge of the manual pages, and syntax
- 1.2.1.1 other languages are easy to use for those that are experienced
- 1.2.1.1.1 perhaps "easy to learn" is a better claim
- 1.2.1.1.1.1 why?
- 1.2.1.1.1.1.1 it's easier to learn in some respects, because the syntax is perhaps more consistent
- 1.2.1.1.1.1.2 some people may learn other languages more easily
- 1.2.1.1.1.1.2.1 what does Tcl offer over those other languages?
- 1.2.1.1.1.1.2.1.1 [cycle to root/1]
- 1.3 easier to debug than some other languages
- 1.3.1 the stack traces are generally easy to read and understand
- 1.3.1.1 why is this important?
- 1.3.1.1.1 this has helped me understand where a bug is in the program
- 1.3.1.1.1.1 Tcl often needs runtime testing where other languages may not
- 1.3.1.1.1.1.1 there are static analysis tools
- 1.3.1.1.1.1.1.1 these are often ineffective with some programming patterns, and give false warnings
- 1.3.1.1.1.1.1.1.1 why is this important?
- 1.3.1.1.1.1.1.1.1.1 I want to find and eliminate as many bugs as possible
- 1.3.1.1.1.1.1.1.1.1.1 most good programs have extensive test suites
- 1.3.1.1.1.1.1.1.1.1.1.1 it's difficult to prove the correctness of a program when so much is dependent on runtime
- 1.3.1.1.1.1.1.1.1.1.1.1.1 why is it difficult to prove correctness?
- 1.3.1.1.1.1.1.1.1.1.1.1.1.1 when the input data is dynamic, less is known about what is valid. when the types may change over time, or perhaps be invalid in some cases, the correctness is difficult to determine
- 1.4 good socket abstraction
- 1.4.1 this allows me to build servers, and clients more easily
- 1.4.1.1 why?
- 1.4.1.1.1 [see 1.4.2 and 1.4.3]
- 1.4.2 the quality of the network programs is generally better
- 1.4.3 the exception mechanism eliminates the need for some error checking or use of [catch]
- 1.4.3.1 why is this important?
- 1.4.3.1.1 error handling and passing failure up to a caller is painful
- 1.4.3.1.1.1 is there a better way that hasn't been considered?
- 1.4.3.1.1.2 error handling in a callee often requires changing the caller (in hindsight)
- 1.4.3.1.1.2.1 why don't you use a design that considers that?
- 1.4.3.1.1.2.1.1 I find it difficulit to keep all of the constraints or possible uses of a program in mind at once.
- 1.5 good event loop
- 1.5.1 the event loop allows reusing a single thread in a process in a way that allows working with many file descriptors
- 1.5.1.1 why is this a good thing?
- 1.5.1.1.1 it's easier to work with generally than using threads
- 1.5.1.1.1.1 why not use more processes with a channel mechanism like what Alef and some other languages do?
- 1.5.1.1.1.1.1 the Alef language was used with Plan 9, and Plan 9 doesn't support a select or poll syscall [may not be accurate now]
- 1.5.1.1.1.1.1.1 why does this matter?
- 1.5.1.1.1.1.1.1.1 with Alef they tend to use a process when they have a blocking resource, and IIRC they don't support non-blocking I/O in Plan 9.
- 1.5.1.1.1.1.1.1.2 Alef/Plan 9 may not be as scalable, there are process limits, and schedulers tend to perform worse with many processes.
- 1.5.1.1.1.1.1.1.2.1 what if the processor or a co-processor contained the scheduler, and register sets, like in Nvidia's CUDA?
- 1.5.1.1.1.1.1.1.2.1.1 that type of architecture would radically change the structure of our existing systems
- 1.5.1.1.1.1.1.1.2.1.2 it would eliminate indirection
- 1.5.1.1.1.1.1.1.2.1.3 scheduling algorithms might not be as flexible, and the knowledge from the I/O scheduler may be difficult to integrate into the priority of the process scheduler
- 1.5.1.1.1.1.1.1.2.1.3.1 the removal of indirection may improve performance in general, so that may not matter so much
- 1.5.1.1.1.2 there is generally no need for a mutex or locking at the Tcl level
- 1.5.1.1.1.2.1 why is this useful?
- 1.5.1.1.1.2.1.1 helps eliminate deadlocks
- 1.5.1.1.1.2.1.2 why is this important?
- 1.5.1.1.1.2.1.2.1 deadlocks can be difficult to detect, and debug
- 1.5.1.1.1.2.1.1.1.1 why are deadlocks difficult to detect and debug?
- 1.5.1.1.1.2.1.1.1.1.1 proper locking often requires analyzing a code path multiple times, with the knowledge of somewhat related state, in order to eliminate race conditions, or to ensure that a callee doesn't try to reacquire the currently used mutex (unless using a recursive mutex) which would lead to deadlock.
- 1.5.1.1.1.2.1.1.1.1.1.1 why not use a recursive mutex in general?
- 1.5.1.1.1.2.1.1.1.1.1.1.1 a recursive mutex may not perform as well, because it may require more atomic operations
- 1.5.1.1.1.2.1.1.1.1.1.1.2 a recursive mutex requires more work to setup than a normal mutex (in general)
- 1.6 extendable in C
- 1.6.1 C is the most common language
- 1.6.1.1 many useful libraries provide a C API
- 1.6.1.1.1 why is this important?
- 1.6.1.1.1.1 it helps me to achieve more in less time
- 1.6.1.1.1.1.1 why is this important?
- 1.6.1.1.1.1.1.1 I want to do more on my own, and not duplicate effort
- 1.6.1.1.1.1.1.2 it may not be as important as I think at times, because if I could form a group that would help me build a project, I could do more as well, without C
- 1.6.1.1.2 many libraries seem to duplicate common patterns
- 1.6.1.1.2.1 why does this matter?
- 1.6.1.1.2.1.1 the code could be more simple in some way
- 1.6.1.1.2.1.2 at some level all code in a process is just a blob of bytes
- 1.6.1.1.2.1.3 more bugs!
- 1.6.1.1.2.1.3.1 why not reuse that code in every library to avoid bugs?
- 1.6.1.1.2.1.3.1.1 C is somewhat limited with regard to exposing names to the outside world
- 1.6.1.1.2.1.3.1.1.1 what if C had a module API with the ability for the module user to choose the name?
- 1.6.1.1.2.1.3.1.1.1.1 it would probably require toolchain changes, and at this point such changes are not realistic
- 1.6.1.1.2.1.3.1.2 reuse would require multiple groups working together towards a common pattern
- 1.6.1.1.2.1.3.1.2.1 politics would probably be a problem, and there are different ideas regarding C style
- 1.6.1.1.2.1.3.1.3 the effort and time required to work towards reuse in those libraries might exceed any time or effort saved