Posted to tcl by gps at Mon Jun 08 16:28:13 GMT 2009view raw

  1. Below is some notation I use for representing what forms a thought.
  2.  
  3. 1 like Tcl ->
  4.  
  5. 1.1 community
  6. 1.1.1 most of the community is helpful and friendly
  7. 1.1.1.1 why does this matter?
  8. 1.1.1.1.1 those that are helpful encourage sharing of ideas, and we help each other improve
  9. 1.1.1.1.2 it tends to lead to fewer volatile feelings
  10. 1.2 general ease of use
  11. 1.2.1 this may be based on my experience, and knowledge of the manual pages, and syntax
  12. 1.2.1.1 other languages are easy to use for those that are experienced
  13. 1.2.1.1.1 perhaps "easy to learn" is a better claim
  14. 1.2.1.1.1.1 why?
  15. 1.2.1.1.1.1.1 it's easier to learn in some respects, because the syntax is perhaps more consistent
  16. 1.2.1.1.1.1.2 some people may learn other languages more easily
  17. 1.2.1.1.1.1.2.1 what does Tcl offer over those other languages?
  18. 1.2.1.1.1.1.2.1.1 [cycle to root/1]
  19. 1.3 easier to debug than some other languages
  20. 1.3.1 the stack traces are generally easy to read and understand
  21. 1.3.1.1 why is this important?
  22. 1.3.1.1.1 this has helped me understand where a bug is in the program
  23. 1.3.1.1.1.1 Tcl often needs runtime testing where other languages may not
  24. 1.3.1.1.1.1.1 there are static analysis tools
  25. 1.3.1.1.1.1.1.1 these are often ineffective with some programming patterns, and give false warnings
  26. 1.3.1.1.1.1.1.1.1 why is this important?
  27. 1.3.1.1.1.1.1.1.1.1 I want to find and eliminate as many bugs as possible
  28. 1.3.1.1.1.1.1.1.1.1.1 most good programs have extensive test suites
  29. 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
  30. 1.3.1.1.1.1.1.1.1.1.1.1.1 why is it difficult to prove correctness?
  31. 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
  32. 1.4 good socket abstraction
  33. 1.4.1 this allows me to build servers, and clients more easily
  34. 1.4.1.1 why?
  35. 1.4.1.1.1 [see 1.4.2 and 1.4.3]
  36. 1.4.2 the quality of the network programs is generally better
  37. 1.4.3 the exception mechanism eliminates the need for some error checking or use of [catch]
  38. 1.4.3.1 why is this important?
  39. 1.4.3.1.1 error handling and passing failure up to a caller is painful
  40. 1.4.3.1.1.1 is there a better way that hasn't been considered?
  41. 1.4.3.1.1.2 error handling in a callee often requires changing the caller (in hindsight)
  42. 1.4.3.1.1.2.1 why don't you use a design that considers that?
  43. 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.
  44. 1.5 good event loop
  45. 1.5.1 the event loop allows reusing a single thread in a process in a way that allows working with many file descriptors
  46. 1.5.1.1 why is this a good thing?
  47. 1.5.1.1.1 it's easier to work with generally than using threads
  48. 1.5.1.1.1.1 why not use more processes with a channel mechanism like what Alef and some other languages do?
  49. 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]
  50. 1.5.1.1.1.1.1.1 why does this matter?
  51. 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.
  52. 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.
  53. 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?
  54. 1.5.1.1.1.1.1.1.2.1.1 that type of architecture would radically change the structure of our existing systems
  55. 1.5.1.1.1.1.1.1.2.1.2 it would eliminate indirection
  56. 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
  57. 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
  58. 1.5.1.1.1.2 there is generally no need for a mutex or locking at the Tcl level
  59. 1.5.1.1.1.2.1 why is this useful?
  60. 1.5.1.1.1.2.1.1 helps eliminate deadlocks
  61. 1.5.1.1.1.2.1.2 why is this important?
  62. 1.5.1.1.1.2.1.2.1 deadlocks can be difficult to detect, and debug
  63. 1.5.1.1.1.2.1.1.1.1 why are deadlocks difficult to detect and debug?
  64. 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.
  65. 1.5.1.1.1.2.1.1.1.1.1.1 why not use a recursive mutex in general?
  66. 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
  67. 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)
  68.  
  69. 1.6 extendable in C
  70. 1.6.1 C is the most common language
  71. 1.6.1.1 many useful libraries provide a C API
  72. 1.6.1.1.1 why is this important?
  73. 1.6.1.1.1.1 it helps me to achieve more in less time
  74. 1.6.1.1.1.1.1 why is this important?
  75. 1.6.1.1.1.1.1.1 I want to do more on my own, and not duplicate effort
  76. 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
  77. 1.6.1.1.2 many libraries seem to duplicate common patterns
  78. 1.6.1.1.2.1 why does this matter?
  79. 1.6.1.1.2.1.1 the code could be more simple in some way
  80. 1.6.1.1.2.1.2 at some level all code in a process is just a blob of bytes
  81. 1.6.1.1.2.1.3 more bugs!
  82. 1.6.1.1.2.1.3.1 why not reuse that code in every library to avoid bugs?
  83. 1.6.1.1.2.1.3.1.1 C is somewhat limited with regard to exposing names to the outside world
  84. 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?
  85. 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
  86. 1.6.1.1.2.1.3.1.2 reuse would require multiple groups working together towards a common pattern
  87. 1.6.1.1.2.1.3.1.2.1 politics would probably be a problem, and there are different ideas regarding C style
  88. 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
  89.