If one did it right you wouldn't notice it. Its impossible to do it right on each platform supported by a toolkit (at least Unix/Linux kills you with the horrible mix of different WMs and Toolkits each with its own strange configuration system thats slightly different from anybody elses). But you can do it on some platforms you care for, usually its windows, OS X and one of the many Unix WMs.
And your argument is rather weak, either you care to really match the look and feel of the platform, or you say 80% is enough and stop there. Basically you have choices to make where to distribute your work power, either you enable your program to work 80% in lots of environments and fix the most cruel usuability bugs when they get reported, or you go to support one platform 100% and drop nearly all the others. If you can do both, due to excessive amounts of money, volunteers or other things, your just lucky.
Actually there is now a command in unsupported:: namespace to inspect the bytecodes produced by a proc and better support for finding the line number of a defined proc, which helps debugger writers.
Michael
Application programmers don't invest time to polish their apps, you can do a lot even with Tk 8.4 but many programmers just don't invest time or don't have some graphics designer at hand to do nice icons and stuff.
No antialiased fonts in Tk before Tk 8.5, so fonts look like the standard legacy X11 bitmapped fonts they are.
Motif imitating default style. Its dated but was the right thing some decades ago...
Tk has to play catch up, because other toolkits try to define the default looks (GTK and QT) on linux, they even try to redefine parts of X, sometimes breaking compatibility with other Toolkits at a whim.
Lookup the chameleon package from AMSN, it does automatic conversion of most old Tk widgets to new Ttk widgets, or at least eases the transition a lot.
Only if someone does the Tk port for Perl/Tk because they stripped Tcl out of the mix the perl/Tk devs need to do a lot more work than necessary. But maybe look at the Perl::Tk module in CPAN...
Sure you can load the burden onto the compiler of all languages you want to port, instead of making the VM more flexible and support dynamic features. Look at the Intel/HP Itanium processors non-success how well it works to put the burden on the compiler writers.
If you add some nice opcodes to the VM you can save lots of compiler writers from doing extremly complex translations all over the place. Try for example to compile Tcl code to Java Bytecodes, especially with things like variable and command traces, redefining core commands on the fly and so on. There is a reason most languages under the Java VM are mostly interpreters, not compilers. Doing good compilers for dynamic languages is hard.
The only reason Sun could get away with burdening the compiler writers with the trouble of working around the shortcomings of the Java VM is the pure marketshare of Java. Quite similar to the strategy of Microsoft with.NET/CLR.
Depending on what your comfortable with, Tcl/Tk is also a good solution for cross platform GUI development, with the new tile theming engine you can even blend into Qt themes or Windows XP themes or Mac OS X Aqua themes without major problems.
Python an Qt are good choices too, for some problems. But its primarily personal preference.
Tcl is somewhat of a strange beast to learn, so easy you have to 'unlearn' lots of habits you could have from coding Perl, C or VB. Things often are easier than expected and really straight forward, especially when it comes to cross platform stuff. Its not uncommon for Tcl/Tk apps to be developed mostly on one platform, say for example Linux or Solaris and then moved to OS X or Windows to do some polishing and work on the details. But all of the core functionalities are totally cross platform. (Qt offers this in a similar way, but is much more heavyweight, and a more inconvenient license on windows).
If you have to go cross platform and want easy deployabiliy, take a look at Tcl and Tk. They just work.
But back to VB. If you are happy with all the pre-made components and want to built your app from those lego like building blocks for windows only, fine. VB is a good choice. You have to live with Microsofts product policy, which may screw you sometimes, but otherwise fine.
Michael
I think you miss the point here:
- Flexibility of the language means you can create a more powerful domain specific language
- Convention over configuration means you have reasonable defaults
RoR has both.
The flexibility of Ruby was used to create a powerful domain specific language for creating database backed website: Ruby on Rails
This domain specific language has very reasonable default settings and the right language constructs for the problem domain, which make further configuration unnecessary for most cases, also you can configure things if you have to.
Tcl is more powerful in the 'flexibility' domain then Ruby, you can create more powerful domain specific languages with Tcl then you can with Ruby. No one did yet for the web domain.
Your Perl examples just shows a programmer going to where madness is.
If you define a powerful domain specific language you raise the abstraction level for solving your domains problems. This brings you the increase in productivity RoR shows so dramatically.
Designing a good domain specific language is hard. If you just litter shorthand notations in your code you don't design a good domain specific language, you define shorthands to save some keystrokes, but do not raise the abstraction level.
Michael
Tcl isn't commercially dead. Its just nearly invisible for most commercial uses.
You have: - BSD license -> no need to advertise the use - Easily embedabble -> no simple sign of tcl in the filesystem if done right - highly configurable -> You won't recognize many Tcl scripts as Tcl if you see them, because you can do radical domain specific languages including new control structures, new object oriented paradigms, new assignement operators, etc. etc. - stable and well tested -> You don't have as many users crying out because things are obscure, cryptic, under documented or plain stupid - binary compatibility for extension since Tcl 8.1 (about seven years!!) -> With the Tcl stubs layer you don't need to compile all your extensions for use with a newer Tcl version, unlike many other dynamic languages, where C-coded extensions need to be in version lockstep, so you don't see as many 'maintenance releases', because they are not needed.
But if you generalize from a view 10.000 ft above reality, you may come to wrong conclusions.
If you don't like whats provided by your ssh client, how about wrapping a windows commandline ssh client like putty with Expect? http://expect.nist.gov/ for Expect and some usage examples http://tcl.activestate.com/ for Expect for Windows
Just define all the convenience functions you need as simple expect scripts and don't look back. If you like GUIs add some trivial Tk code.
Re:Opensource GUI Toolkits in a nutshell
on
Why Use GTK+?
·
· Score: 1
tk - its dead, forget about it, its really low level, and looks like ass everywhere.
Tk isn't dead. Call it mature (or dying if your pessimistic, your choice).
Try looking at the screenshots at:
http://tktable.sourceforge.net/tile/
If you replace 'ass' with 'Motif', your right that Tk's default look is very much Motif and dated.
Tcl/Tk does not really have a problem with kernel 2.6, AFAIK its a glibc bug in the thread implementation which interacts with a newer kernel threading model and causes threaded Tcl/Tk builds to hang. (java hangs in similar ways...). Primitive workaround is to use the non-threaded builds of Tcl/Tk which are faster anyway.
(Debian is currently the only distro which builds a threaded Tcl 8.4 as default due to the aolserver package needing a threaded Tcl, but threaded Tcl will probably become default with Tcl 8.5)
Fat cross platform binaries, just do it
on
Why Use GTK+?
·
· Score: 1
Or do a transaction safe differential update of the app from the internet server with: sdx update myapp.kit
And yes, you can build fat binaries which can include compiled C libraries for use on Mac/Linux/Windows. If they use the Tcl Stubs mechanism you do not even need the same Tcl version for the runtime you used for the libraries, no recompile of library packages for minor version changes. (thats currently 7 years of no recompiles for most Tcl extensions).
Re:how about other toolkits?
on
Why Use GTK+?
·
· Score: 2, Interesting
Badly written Tk looks horribly Motif like and dated. Good Tk (with theming thanks to the tile project
http://tktable.sourceforge.net/tile/ ) can look quite nice an modern, take a look at the screenshots.
Its just the little extra polish thats often missing in Tk apps, because the authors are adding features instead of polishing the GUI.
Slashdot Mirror
If one did it right you wouldn't notice it. Its impossible to do it right on each platform supported by a toolkit (at least Unix/Linux kills you with the horrible mix of different WMs and Toolkits each with its own strange configuration system thats slightly different from anybody elses). But you can do it on some platforms you care for, usually its windows, OS X and one of the many Unix WMs. And your argument is rather weak, either you care to really match the look and feel of the platform, or you say 80% is enough and stop there. Basically you have choices to make where to distribute your work power, either you enable your program to work 80% in lots of environments and fix the most cruel usuability bugs when they get reported, or you go to support one platform 100% and drop nearly all the others. If you can do both, due to excessive amounts of money, volunteers or other things, your just lucky.
Actually there is now a command in unsupported:: namespace to inspect the bytecodes produced by a proc and better support for finding the line number of a defined proc, which helps debugger writers. Michael
Lookup the chameleon package from AMSN, it does automatic conversion of most old Tk widgets to new Ttk widgets, or at least eases the transition a lot.
Only if someone does the Tk port for Perl/Tk because they stripped Tcl out of the mix the perl/Tk devs need to do a lot more work than necessary. But maybe look at the Perl::Tk module in CPAN...
Sure you can load the burden onto the compiler of all languages you want to port, instead of making the VM more flexible and support dynamic features. Look at the Intel/HP Itanium processors non-success how well it works to put the burden on the compiler writers.
If you add some nice opcodes to the VM you can save lots of compiler writers from doing extremly complex translations all over the place. Try for example to compile Tcl code to Java Bytecodes, especially with things like variable and command traces, redefining core commands on the fly and so on. There is a reason most languages under the Java VM are mostly interpreters, not compilers. Doing good compilers for dynamic languages is hard.
The only reason Sun could get away with burdening the compiler writers with the trouble of working around the shortcomings of the Java VM is the pure marketshare of Java. Quite similar to the strategy of Microsoft with .NET/CLR.
You could also take a look at SourceNavigator at http://sourcenav.sourceforge.net/index.html.
Depending on what your comfortable with, Tcl/Tk is also a good solution for cross platform GUI development, with the new tile theming engine you can even blend into Qt themes or Windows XP themes or Mac OS X Aqua themes without major problems. Python an Qt are good choices too, for some problems. But its primarily personal preference. Tcl is somewhat of a strange beast to learn, so easy you have to 'unlearn' lots of habits you could have from coding Perl, C or VB. Things often are easier than expected and really straight forward, especially when it comes to cross platform stuff. Its not uncommon for Tcl/Tk apps to be developed mostly on one platform, say for example Linux or Solaris and then moved to OS X or Windows to do some polishing and work on the details. But all of the core functionalities are totally cross platform. (Qt offers this in a similar way, but is much more heavyweight, and a more inconvenient license on windows). If you have to go cross platform and want easy deployabiliy, take a look at Tcl and Tk. They just work. But back to VB. If you are happy with all the pre-made components and want to built your app from those lego like building blocks for windows only, fine. VB is a good choice. You have to live with Microsofts product policy, which may screw you sometimes, but otherwise fine. Michael
I think you might like visitors: http://www.hping.org/visitors/
I think you miss the point here: - Flexibility of the language means you can create a more powerful domain specific language - Convention over configuration means you have reasonable defaults RoR has both. The flexibility of Ruby was used to create a powerful domain specific language for creating database backed website: Ruby on Rails This domain specific language has very reasonable default settings and the right language constructs for the problem domain, which make further configuration unnecessary for most cases, also you can configure things if you have to. Tcl is more powerful in the 'flexibility' domain then Ruby, you can create more powerful domain specific languages with Tcl then you can with Ruby. No one did yet for the web domain. Your Perl examples just shows a programmer going to where madness is. If you define a powerful domain specific language you raise the abstraction level for solving your domains problems. This brings you the increase in productivity RoR shows so dramatically. Designing a good domain specific language is hard. If you just litter shorthand notations in your code you don't design a good domain specific language, you define shorthands to save some keystrokes, but do not raise the abstraction level. Michael
Tcl isn't commercially dead. Its just nearly invisible for most commercial uses.
You have:
- BSD license -> no need to advertise the use
- Easily embedabble -> no simple sign of tcl in the filesystem if done right
- highly configurable -> You won't recognize many Tcl scripts as Tcl if you see them, because you can do radical domain specific languages including new control structures, new object oriented paradigms, new assignement operators, etc. etc.
- stable and well tested -> You don't have as many users crying out because things are obscure, cryptic, under documented or plain stupid
- binary compatibility for extension since Tcl 8.1 (about seven years!!) -> With the Tcl stubs layer you don't need to compile all your extensions for use with a newer Tcl version, unlike many other dynamic languages, where C-coded extensions need to be in version lockstep, so you don't see as many 'maintenance releases', because they are not needed.
But if you generalize from a view 10.000 ft above reality, you may come to wrong conclusions.
Michael
If you don't like whats provided by your ssh client, how about wrapping a windows commandline ssh client like putty with Expect?
http://expect.nist.gov/ for Expect and some usage examples
http://tcl.activestate.com/ for Expect for Windows
Just define all the convenience functions you need as simple expect scripts and don't look back. If you like GUIs add some trivial Tk code.
Tcl/Tk does not really have a problem with kernel 2.6, AFAIK its a glibc bug in the thread implementation which interacts with a newer kernel threading model and causes threaded Tcl/Tk builds to hang. (java hangs in similar ways...). Primitive workaround is to use the non-threaded builds of Tcl/Tk which are faster anyway. (Debian is currently the only distro which builds a threaded Tcl 8.4 as default due to the aolserver package needing a threaded Tcl, but threaded Tcl will probably become default with Tcl 8.5)
Another variant for Tcl/Tk with Tclkit:
http://www.equi4.com/tclkit
Create a starkit with:
sdx wrap myapp
Run it on any of the supported platforms for Tclkit (30 or so http://www.equi4.com/pub/tk/downloads.html) with:
tclkit myapp.kit
Or do a transaction safe differential update of the app from the internet server with:
sdx update myapp.kit
And yes, you can build fat binaries which can include compiled C libraries for use on Mac/Linux/Windows. If they use the Tcl Stubs mechanism you do not even need the same Tcl version for the runtime you used for the libraries, no recompile of library packages for minor version changes. (thats currently 7 years of no recompiles for most Tcl extensions).
Badly written Tk looks horribly Motif like and dated. Good Tk (with theming thanks to the tile project http://tktable.sourceforge.net/tile/ ) can look quite nice an modern, take a look at the screenshots. Its just the little extra polish thats often missing in Tk apps, because the authors are adding features instead of polishing the GUI.