3 ms·

Yeah, agreed, and we still use it so we made a little C like language that compiles to tcl byte codes. Makes coding there far far more pleasant (for me at leas

Yeah, agreed, and we still use it so we made a little C like language that compiles to tcl byte codes. Makes coding there far far more pleasant (for me at least). http://www.mcvoy.com/lm/L/L.html http://www.mcvoy.com/lm/L/L.html

hardwaresofton 12y ago
Excuse me for asking, but are you doing IC? If not, what is tying you to TCL? legacy software? Also, why not just interface away from TCL? I'm trying not to be too negative on TCL, but it's just not worth the trouble. Now, if someone built a lisp on top of tcl, I might use it, but things like having a { in the comments or spacing out opening {s for a loop is a ridiculous problem for a parser to fall down on (with a non-intuitive error message to boot). Also, you guys are throwing away the good (lispy) parts of tcl by having a C like language (the syntactic consistency, meta-programming by creating variables dynamically,etc)... Also, I bet people have to do some "training" to get up to speed on which parts of the C-like language are which, which generally leads to Not to sound arrogant, but if I was working with you guys, my first 20% time project would be to convert whatever it was that was tying us to TCL to something else, unless it was super duper impossible (like it was in IC). It's just a productivity killer, in my experience.
- cnvogel 12y ago
  In ASIC design (that's what the commenter probably refers to when mentioning IC), just like in the more widespread FPGA world: many of the proprietary expensive tools are exposing their functionality as aTCL scripting engine. While the graphical tools hide this to some extent, as soon as you go for automation, which is unavoidable for complex work, you'll find yourself to write scripts in the TCL language.
  - hardwaresofton 12y ago
    Oh -- I am the original commenter (haha), I was just trying to not assume that they were working in IC design. what you've said is absolutely true -- just wanted to see if that was the case
- luckydude 12y ago
  Sorry, didn't see this until now. We do cross platform gui apps in L/Tk for our source management system. We're pretty small so doing native apps for Windows/Mac/Linux is a lot more work than doing it once. Yeah, the hassle of making them look good is true but not as true as people claim it is (see my other post above). We looked at Qt and I didn't want to bite of C++ on all our ancient platforms we support. I'm a C kinda guy, I like looking at things and understanding it quickly (when going into new code I tend to read the .h files and find the structure definitions, that tells me a lot). Most scripting languages don't have structs (they use a hash instead which means you never really know what is in there unless you find every single assignment to it and memorize all the keys).
  - hardwaresofton 12y ago
    Hey thanks for the reply, was very curious what you were using it for... So, this is pretty crazy, but why not try a small rewrite of some non-trivial functionality in Go? Other than being a language hipster (which I admit I am a little bit), I point to these reasons: 1. Go's ease of cross-compilation is outstanding, so much so that everything else I think of (java, python, C/C++) are not as easy http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c... 2. Go is trying to be used in a "systems language" context, so it's relatively quick 3. It's not C++, and is relatively safer If you're with me till now, then you've realized the real problem with something like Go for this is the GUI library -- unfortunately there are not enough that have been around long enough to be as stable/trusted as TCL/TK.... so that's a bit of a problem. You could also make the UI to your app a website, rather than a GUI application? -------------- OR -------------- What about a your-app-is-a-website type framework like TideSDK? http://www.tidesdk.org/ http://www.tidesdk.org/ You can encapsulate and separate your engine code (which is doing the heavy listing), and just have the client be something that sits on top of it. Sorry, these solutions are quite pie-in-the-sky and I'm sure that you guys are focusing on getting things done (for which L/Tk is perfectly fine), but if you guys are small, I think you might have the agility to move onto a different solution, and I can't help but suggest these things, because I think working on a TCL/TK stack might get things done, but you're gaining experience in a technology that is thoroughly antiquated... So yes, you'll get things done, and you guys will do a great job, but at the end of the day, when it comes time to move to something else, not a lot of the knowledge you gained will be useful?

hardwaresofton 12y ago

Excuse me for asking, but are you doing IC? If not, what is tying you to TCL? legacy software? Also, why not just interface away from TCL? I'm trying not to be too negative on TCL, but it's just not worth the trouble. Now, if someone built a lisp on top of tcl, I might use it, but things like having a { in the comments or spacing out opening {s for a loop is a ridiculous problem for a parser to fall down on (with a non-intuitive error message to boot). Also, you guys are throwing away the good (lispy) parts of tcl by having a C like language (the syntactic consistency, meta-programming by creating variables dynamically,etc)... Also, I bet people have to do some "training" to get up to speed on which parts of the C-like language are which, which generally leads to Not to sound arrogant, but if I was working with you guys, my first 20% time project would be to convert whatever it was that was tying us to TCL to something else, unless it was super duper impossible (like it was in IC). It's just a productivity killer, in my experience.

cnvogel 12y ago
In ASIC design (that's what the commenter probably refers to when mentioning IC), just like in the more widespread FPGA world: many of the proprietary expensive tools are exposing their functionality as aTCL scripting engine. While the graphical tools hide this to some extent, as soon as you go for automation, which is unavoidable for complex work, you'll find yourself to write scripts in the TCL language.
- hardwaresofton 12y ago
  Oh -- I am the original commenter (haha), I was just trying to not assume that they were working in IC design. what you've said is absolutely true -- just wanted to see if that was the case
luckydude 12y ago
Sorry, didn't see this until now. We do cross platform gui apps in L/Tk for our source management system. We're pretty small so doing native apps for Windows/Mac/Linux is a lot more work than doing it once. Yeah, the hassle of making them look good is true but not as true as people claim it is (see my other post above). We looked at Qt and I didn't want to bite of C++ on all our ancient platforms we support. I'm a C kinda guy, I like looking at things and understanding it quickly (when going into new code I tend to read the .h files and find the structure definitions, that tells me a lot). Most scripting languages don't have structs (they use a hash instead which means you never really know what is in there unless you find every single assignment to it and memorize all the keys).
- hardwaresofton 12y ago
  Hey thanks for the reply, was very curious what you were using it for... So, this is pretty crazy, but why not try a small rewrite of some non-trivial functionality in Go? Other than being a language hipster (which I admit I am a little bit), I point to these reasons: 1. Go's ease of cross-compilation is outstanding, so much so that everything else I think of (java, python, C/C++) are not as easy http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c... 2. Go is trying to be used in a "systems language" context, so it's relatively quick 3. It's not C++, and is relatively safer If you're with me till now, then you've realized the real problem with something like Go for this is the GUI library -- unfortunately there are not enough that have been around long enough to be as stable/trusted as TCL/TK.... so that's a bit of a problem. You could also make the UI to your app a website, rather than a GUI application? -------------- OR -------------- What about a your-app-is-a-website type framework like TideSDK? http://www.tidesdk.org/ http://www.tidesdk.org/ You can encapsulate and separate your engine code (which is doing the heavy listing), and just have the client be something that sits on top of it. Sorry, these solutions are quite pie-in-the-sky and I'm sure that you guys are focusing on getting things done (for which L/Tk is perfectly fine), but if you guys are small, I think you might have the agility to move onto a different solution, and I can't help but suggest these things, because I think working on a TCL/TK stack might get things done, but you're gaining experience in a technology that is thoroughly antiquated... So yes, you'll get things done, and you guys will do a great job, but at the end of the day, when it comes time to move to something else, not a lot of the knowledge you gained will be useful?