4 ms·

1994? How about 2016 and I'm still living in a nightmare - my company uses tcl ("legacy" scripts). No matter how many times I tried to approach the language wit

by Paul_S 10y ago

1994? How about 2016 and I'm still living in a nightmare - my company uses tcl ("legacy" scripts). No matter how many times I tried to approach the language with an open mind there is no other language that grinds me down as much. If you think passing a variable name in a string to a function and then using upvar to access it is an acceptable way of returning values then have I got good news for you - we have languages with a sane way of doing it today (heck we've had them for longer than tcl has been around for)! I die every time I have to look up which order arguments come in because of how inconsistent it is, and oh, is it append or lappend or some other crazy keyword? People at the office had this for decades and they still have to use a cheat sheet. Why... There's perl, python, bash, anything god, please, make it stop.

jt2190 10y ago
[Warning: Personal anecdote... somewhat off topic.] Around 2003 I was getting very heavily into what we used to call "Dynamic HTML", which of course required programming in JavaScript. At the time JavaScript was looked down upon by most professional programmers as a toy. A toy that had buggy implementations in various browsers, that lacked the strict typing of C++ or Java, that didn't have classical inheritance, that had no good IDE, and, worst of all, that you could create some terribly confusing bugs with. At the time I'd moved to Fort Worth which let me attend the monthly Pragmatic Programmers meetings/dinners at Spring Creek Barbeque in Addison, TX. This was a meeting with a lot of polyglot programmers and "old timers", and there was a prevailing attitude that programming languages were just tools, and a good programmer learned to use many tools well. Anyway, there I was one night ranting about JavaScript to someone I only remember as Chris. I probably chewed his ear off for a long time about how terrible JavaScript was. After what I'm sure was many minutes, I paused to let Chris tell me how much he agreed that JavaScript was terrible. Instead, he simply said: "You need to learn about prototypical inheritance." This caught me off guard. I don't remember if it shut me up, but I hope it did. Fortunately I actually took Chris' advice. While I'd understood that JavaScript had prototypical inheritance, I'd never really taken the time to understand how it really worked. I'd also never really grokked how scopes worked. As I properly learned these features, I started to gain a new respect for the power of the language, and it quickly became my favorite. So, now when I have a strong negative reaction to a new language or tool, I ask myself if I'm reacting because of a fault in the language or if I just don't like that feeling of being less productive because I haven't learned the language yet. Usually it's the latter, which means I need to grit my teeth and bend my brain and learn. (P.S. Chris, if you're reading this: Thank you! I owe you a millions lines of code in grattitude!)
- frozenport 10y ago
  TCL is the counter example to this point :-)
- glv 10y ago
  I'm pretty sure that was Chris Morris. (He and I were both regulars at that group.)
  - jt2190 10y ago
    Hi Glenn :-) I could have sworn it was a _different_ Chris. I remember someone with black hair. He may not have frequented the meeting as much, because I don't remember seeing him again after that. (P.S. I've updated my profile.)
    - glv 10y ago
      Ah, OK. (And yes, I remember you. You ran the FW JUG for a while?)
      - jt2190 10y ago
        Yes, that was me.
- groovy2shoes 10y ago
  > At the time JavaScript was looked down upon by most professional programmers as a toy. A toy that had buggy implementations in various browsers, that lacked the strict typing of C++ or Java, that didn't have classical inheritance, that had no good IDE, and, worst of all, that you could create some terribly confusing bugs with. This is how I still view JavaScript.
- codygman 10y ago
  Whoa, people from the dfw area on HN!
ArkyBeagle 10y ago
I had essentially the same relationship with Tcl until I went through the Brent Welch book in great detail. From that point on, the only real cost in using it became not remembering the ... soup of what I ( or someone else ) had done when returning to old code. That's true of anything. I presume that by "look up in which order..." refers to lsearch vs "string first". Yup. Annoying; one's "needle haystack" the other is other way 'round. This being said, I am skeptical that this grinds anyone down. It'd have to be one grain of sand on a piece sandpaper. My experience with Tcl is mainly that if I have to extend or modify a script, some care must be taken to design the thing for that upfront. But after a couple decades watching comp.lang.tcl, I think the big leap is that you either embrace the event driven model or it's not nearly as much fun.
- kazinator 10y ago
  > My experience with Tcl is mainly that if I have to extend or modify a script, some care must be taken to design the thing for that upfront. That matches my experience with assembly language. Even in C, I can just begin coding and a good design emerges from prototype code. Months later I understand everything, and have a good time maintaining it.
  - bch 10y ago
    It may be the case that you've got Good Style, for whatever reason (inherent gift, good training, school of experience), but my take ( personal experience/view only ) on the two languages is that C style largely falls out of data structures[0], and Tcl out of action-directive (commands). I think of Tcl as a long lever where a small amount of code lifts a lot, either by composability[1], or leaning on heavy-lifting extensions, but very command-oriented none-the-less. By comparison, I feel my C more often is centered around structs. [0] Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious. -Eric S. Raymond, The Cathedral and the Bazaar [1] http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10 http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10
  - ArkyBeagle 10y ago
    I understand it, it's just that I have to pick at it a while before I do again. Y'know what, though? I don't often have to look at it again.
nilkn 10y ago
I've written some surprisingly complex software in Tcl. It's easily preferable to Perl and Bash to me by an order of magnitude. Python I generally prefer unless I'm working with threads and need parallel execution across cores, in which case Tcl is actually better (unless multiprocessing can handle your use case). By the way, Tcl has full coroutines too: https://www.tcl.tk/man/tcl/TclCmd/coroutine.htm https://www.tcl.tk/man/tcl/TclCmd/coroutine.htm What I've found is that most languages have language smells that you just have to get used to. The same is true of every language you listed there. Using 'upvar' and the like quickly becomes second nature and barely poses a problem in Tcl code.
- kazinator 10y ago
  > It's easily preferable to Perl and Bash to me by an order of magnitude. Given what else you can put into this category, it's not very meaningful.
  - nilkn 10y ago
    Honestly I don't know what this comment means. What category are you talking about, and what else is in it? Those were two languages explicitly mentioned by the comment I was replying to. As I said, there are even cases where I find Tcl to be a better language than something very popular today like Python. Tcl has had features for years or decades that Python has only very recently acquired (full coroutine support, an event loop), and it's still much better for multithreaded programming.
kazinator 10y ago
The exposure of features like "upvar" is the programming language designer saying, "This shit is implemented in exactly one way, which is interpreted, and it will stay that way forever. Thus, here are the run-time keys to the interpreter environment, so you can implement for yourself that which I won't. Good luck!"

by Paul_S 10y ago

jt2190 10y ago

[Warning: Personal anecdote... somewhat off topic.] Around 2003 I was getting very heavily into what we used to call "Dynamic HTML", which of course required programming in JavaScript. At the time JavaScript was looked down upon by most professional programmers as a toy. A toy that had buggy implementations in various browsers, that lacked the strict typing of C++ or Java, that didn't have classical inheritance, that had no good IDE, and, worst of all, that you could create some terribly confusing bugs with. At the time I'd moved to Fort Worth which let me attend the monthly Pragmatic Programmers meetings/dinners at Spring Creek Barbeque in Addison, TX. This was a meeting with a lot of polyglot programmers and "old timers", and there was a prevailing attitude that programming languages were just tools, and a good programmer learned to use many tools well. Anyway, there I was one night ranting about JavaScript to someone I only remember as Chris. I probably chewed his ear off for a long time about how terrible JavaScript was. After what I'm sure was many minutes, I paused to let Chris tell me how much he agreed that JavaScript was terrible. Instead, he simply said: "You need to learn about prototypical inheritance." This caught me off guard. I don't remember if it shut me up, but I hope it did. Fortunately I actually took Chris' advice. While I'd understood that JavaScript had prototypical inheritance, I'd never really taken the time to understand how it really worked. I'd also never really grokked how scopes worked. As I properly learned these features, I started to gain a new respect for the power of the language, and it quickly became my favorite. So, now when I have a strong negative reaction to a new language or tool, I ask myself if I'm reacting because of a fault in the language or if I just don't like that feeling of being less productive because I haven't learned the language yet. Usually it's the latter, which means I need to grit my teeth and bend my brain and learn. (P.S. Chris, if you're reading this: Thank you! I owe you a millions lines of code in grattitude!)

frozenport 10y ago
TCL is the counter example to this point :-)
glv 10y ago
I'm pretty sure that was Chris Morris. (He and I were both regulars at that group.)
- jt2190 10y ago
  Hi Glenn :-) I could have sworn it was a _different_ Chris. I remember someone with black hair. He may not have frequented the meeting as much, because I don't remember seeing him again after that. (P.S. I've updated my profile.)
  - glv 10y ago
    Ah, OK. (And yes, I remember you. You ran the FW JUG for a while?)
    - jt2190 10y ago
      Yes, that was me.
groovy2shoes 10y ago
> At the time JavaScript was looked down upon by most professional programmers as a toy. A toy that had buggy implementations in various browsers, that lacked the strict typing of C++ or Java, that didn't have classical inheritance, that had no good IDE, and, worst of all, that you could create some terribly confusing bugs with. This is how I still view JavaScript.
codygman 10y ago
Whoa, people from the dfw area on HN!

ArkyBeagle 10y ago

I had essentially the same relationship with Tcl until I went through the Brent Welch book in great detail. From that point on, the only real cost in using it became not remembering the ... soup of what I ( or someone else ) had done when returning to old code. That's true of anything. I presume that by "look up in which order..." refers to lsearch vs "string first". Yup. Annoying; one's "needle haystack" the other is other way 'round. This being said, I am skeptical that this grinds anyone down. It'd have to be one grain of sand on a piece sandpaper. My experience with Tcl is mainly that if I have to extend or modify a script, some care must be taken to design the thing for that upfront. But after a couple decades watching comp.lang.tcl, I think the big leap is that you either embrace the event driven model or it's not nearly as much fun.

kazinator 10y ago
> My experience with Tcl is mainly that if I have to extend or modify a script, some care must be taken to design the thing for that upfront. That matches my experience with assembly language. Even in C, I can just begin coding and a good design emerges from prototype code. Months later I understand everything, and have a good time maintaining it.
- bch 10y ago
  It may be the case that you've got Good Style, for whatever reason (inherent gift, good training, school of experience), but my take ( personal experience/view only ) on the two languages is that C style largely falls out of data structures[0], and Tcl out of action-directive (commands). I think of Tcl as a long lever where a small amount of code lifts a lot, either by composability[1], or leaning on heavy-lifting extensions, but very command-oriented none-the-less. By comparison, I feel my C more often is centered around structs. [0] Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious. -Eric S. Raymond, The Cathedral and the Bazaar [1] http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10 http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M10
- ArkyBeagle 10y ago
  I understand it, it's just that I have to pick at it a while before I do again. Y'know what, though? I don't often have to look at it again.

nilkn 10y ago

I've written some surprisingly complex software in Tcl. It's easily preferable to Perl and Bash to me by an order of magnitude. Python I generally prefer unless I'm working with threads and need parallel execution across cores, in which case Tcl is actually better (unless multiprocessing can handle your use case). By the way, Tcl has full coroutines too: https://www.tcl.tk/man/tcl/TclCmd/coroutine.htm https://www.tcl.tk/man/tcl/TclCmd/coroutine.htm What I've found is that most languages have language smells that you just have to get used to. The same is true of every language you listed there. Using 'upvar' and the like quickly becomes second nature and barely poses a problem in Tcl code.

kazinator 10y ago
> It's easily preferable to Perl and Bash to me by an order of magnitude. Given what else you can put into this category, it's not very meaningful.
- nilkn 10y ago
  Honestly I don't know what this comment means. What category are you talking about, and what else is in it? Those were two languages explicitly mentioned by the comment I was replying to. As I said, there are even cases where I find Tcl to be a better language than something very popular today like Python. Tcl has had features for years or decades that Python has only very recently acquired (full coroutine support, an event loop), and it's still much better for multithreaded programming.

kazinator 10y ago

The exposure of features like "upvar" is the programming language designer saying, "This shit is implemented in exactly one way, which is interpreted, and it will stay that way forever. Thus, here are the run-time keys to the interpreter environment, so you can implement for yourself that which I won't. Good luck!"