4 ms·

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 b

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?
  - luckydude 12y ago
    So moving to anything is a pile of work, we have 10 different guis in L/Tk: bk citool - graphical check-in tool bk csettool - graphical changeset browser bk difftool - graphical differences viewer bk fm3tool - three-way merge tool bk fmtool - side-by-side merge tool bk helptool - graphical front-end to the help system bk renametool - graphical tool for finding renames bk revtool - graphical history browser bk setuptool - graphical front-end to the setup command bk explorer - file/repo/branch explorer which is about 26,000 lines of code. We're trying to relaunch the company, we've never done any marketing, just coasted on the rep we got from having the Linux kernel use us for a while. Rewriting all the guis is a big task - we need to focus on stuff that will make money or the whole thing will be a moot point :) And we're gonna open source L pretty soon here so maybe that will breath a little life into the tcl/tk ecosystem (and maybe not, I have no way of knowing). L is pretty pleasant, it has replaced perl as my goto scripting language. I'd love it if gcc had an L dialect.

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?
- luckydude 12y ago
  So moving to anything is a pile of work, we have 10 different guis in L/Tk: bk citool - graphical check-in tool bk csettool - graphical changeset browser bk difftool - graphical differences viewer bk fm3tool - three-way merge tool bk fmtool - side-by-side merge tool bk helptool - graphical front-end to the help system bk renametool - graphical tool for finding renames bk revtool - graphical history browser bk setuptool - graphical front-end to the setup command bk explorer - file/repo/branch explorer which is about 26,000 lines of code. We're trying to relaunch the company, we've never done any marketing, just coasted on the rep we got from having the Linux kernel use us for a while. Rewriting all the guis is a big task - we need to focus on stuff that will make money or the whole thing will be a moot point :) And we're gonna open source L pretty soon here so maybe that will breath a little life into the tcl/tk ecosystem (and maybe not, I have no way of knowing). L is pretty pleasant, it has replaced perl as my goto scripting language. I'd love it if gcc had an L dialect.