Slashdot Mirror

Simple and "does the job"

Cheap (upfront and cost of ownership)

Proven

Fast enough

Why would you take the risk of using an obscure system unless there were a compelling reason to do so?

Also, I've run Apache serving pages and never really noticed any system hogging issues... but I guess it depends what else you're doing. If you're using a 486, you should probably think about upgrading now.

If you write ONLY Java, like I do in our days, its easy: the scripting language will be either Java(Dynamic Java, see: http://koala.ilog.fr/djava/ or Bean Shell, aka bsh, see: http:www.beanshell.org) or Java Script, aka Rhino, see: http://www.mozilla.org/rhino/ or any other language running on a JVM see: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml

You forgot a big one: Tcl. There is a pure Java Tcl interpreter Jacl. It's trivial to embed and use. I've used it to add scripting to tools, and to run the same Tcl scripts on Windows, Linux, Solaris, OS X, all from a single Java jar running on all of those.

Remember, Tcl does stand for "tool command language:. :-)

Tcl/Tk proper is not a bad idea either. If one does not need the GUI part (Tk) then Tcl is relatively easy to integrate into a project, and is under 200k.

HowToEmbed from the Tcl Wiki is a good starting point, and MkTclApp may help.

Tcl has very consistent and simple syntax (although it can get rather confusing at times), and it is very simple to add new command into your application that are exposed via Tcl. One of the nicest aspects of Tcl is that is it seriously multi-platform.

Of course this all depends on the requirements: how powerful does the language need to be, what functions must it provide, what types do you need it to be able to handle, how small is "lightweight", etc.

Tcl/Tk proper is not a bad idea either. If one does not need the GUI part (Tk) then Tcl is relatively easy to integrate into a project, and is under 200k.

HowToEmbed from the Tcl Wiki is a good starting point, and MkTclApp may help.

Tcl has very consistent and simple syntax (although it can get rather confusing at times), and it is very simple to add new command into your application that are exposed via Tcl. One of the nicest aspects of Tcl is that is it seriously multi-platform.

Of course this all depends on the requirements: how powerful does the language need to be, what functions must it provide, what types do you need it to be able to handle, how small is "lightweight", etc.

I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.

I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.

So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.

I could either:

• a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
• b) Use Python and wxPython to provide a GUI application that runs on windows/unix/mac.
• c) Use Tcl/Tk to provide a GUI application that runs on windows/unix/mac.

I eventually chose the tcl/tk option, because of the following reasons:

• 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
• 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
• 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.

So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.

I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.

I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.

So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.

I could either:

• a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
• b) Use Python and wxPython to provide a GUI application that runs on windows/unix/mac.
• c) Use Tcl/Tk to provide a GUI application that runs on windows/unix/mac.

I eventually chose the tcl/tk option, because of the following reasons:

• 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
• 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
• 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.

So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.

I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.

I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.

So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.

I could either:

• a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
• b) Use Python and wxPython to provide a GUI application that runs on windows/unix/mac.
• c) Use Tcl/Tk to provide a GUI application that runs on windows/unix/mac.

I eventually chose the tcl/tk option, because of the following reasons:

• 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
• 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
• 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.

So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.

IMHO, the problem with Swing is mostly that it is horribly overengineered and, frankly, that the implementation sucks. It's all in src.jar - read it and tell me if you would hire someone who would present that piece of crap as their prior experience.

I've found http://www.tcl.tk/ rather handy. Anybody know any good sites for other (more useful) scripting languages in St. Helena (.sh), Poland (.pl), Paraguay (.py), etc.? Or maybe some good linker help in Sierra Leone (.sl) or Somalia (.so)? Sound files from Australia (.au)?

I agree very much with Randolpho's post. Ditch PHP if you really want an elegent architecture. If you really need to stick with PHP, try out Midgard. Otherwise, you really ought to at least look at the alternatives. Zope and OpenACS are probably the best open source web application systems/environments/architectures, whatever you want to call it. I prefer OpenACS (there's just something about using a system that was built primarily by highly intelligent MIT and CalTech alumni...).

OpenACS is based on AOLServer (probably the best, and first application-oriented web server out there, which was GPL'd by AOL thanks to Phil Greenspun's nagging. it's multi-threaded, it has database pooling, a healthy set of modules/plugins, and a wonderful community.), Tcl (you'll get used to it, really ;), and either Oracle or PostgreSQL. Thought it was designed for use with Oracle, and was ported to PostgreSQL, the architecture in OpenACS permits you to easily swap in support for other databases. Though, you'd have an extremely tough time getting it to work in MySQL as it relies on numerous high-end and complex relational databases features, most of which MySQL does not support.

OpenACS is highly modular, built entirely out of smaller packages, with its own package management system. There is a core package, the ACS Kernel, ACS Tcl (which contains most of the utility code, etc.), and there are various packages built on top of that which provide both specific application functionality, but also services that other packages can use. The documentation is built into the code and is available online in every OpenACS installation. Higher up packages include web page creation, bulletin board systems, blogging, content management, etc. You can "mount" these packages at various locations in the site map for your web site / application. E.g., you could mount an instance of the bulletin board at mysite.com/forum, and add a second one at mysite.com/techsupport. You can create subsites, such as mysite.com/internal/. There is an extensive and incredibly powerful permissions system so you can completely control access to every part of your system. There is also a built-in templating system which provides a simple separation between logic and display code, as well as theming capabilities.

I'm sure there's a lot that I've neglected to mention here. But I think you can get the point. OpenACS is a very mature platform that's be in development and production for many years now (hell, take a look at what Ars Digita was able to accomplish, they were making millions selling this system, and they gave the code away for free under the GPL). Don't take my word for it, go to the website and read about it. The only drawback to it that I see is that it does have a high learning curve. It took me a few months of reading and experimenting with it to really understand how the system works, but it's definitely worth it. There are a few hosting providers out there (Acorn Hosting and Zill.net) that offer affordable hosting packages, but it's also easy to setup your own server. OpenACS also has the ability to run multiple server boxes in a load balanced environment, so if you need to scale out, you can. Oh yeah, this is also a descendant of the same ACS system that RedHat's Enterprise Applications are descended from (RedHat got that technology when they bought the remains of ArsDigita.

It might not satisfy all your requirements out of the box, but could you put something together with tcltest?

Tcl's syntax is extremely simple, although slightly more complex than, say, Lisp, in order to make the programmer's life easier.

http://www.tcl.tk/scripting/syntax.html has a good introduction to it - as you can see, anyone can figure it out in a few minutes! Definitely one of Tcl's strong points.

You can get one of the phone versions of the WinCE devices (my brother has the Siemens one - nice device). I have a Toshiba (WinCE without phone). The OS is unicode based (lots of ascii functions are actually missing in the APIs). There are ports of lots of good "traditionally unix" tools at http://www.rainer-keuchel.de/software.html. You can see some of the I18N stuff done with Tcl/Tk on CE and general Tcl/Tk on CE info. Perl/Tk also exists, along with lots of other goodies, at Rainer's site.

The reason that I purchased a WinCE device over Palm was because of all the more fun hack potential.

You can get one of the phone versions of the WinCE devices (my brother has the Siemens one - nice device). I have a Toshiba (WinCE without phone). The OS is unicode based (lots of ascii functions are actually missing in the APIs). There are ports of lots of good "traditionally unix" tools at http://www.rainer-keuchel.de/software.html. You can see some of the I18N stuff done with Tcl/Tk on CE and general Tcl/Tk on CE info. Perl/Tk also exists, along with lots of other goodies, at Rainer's site.

The reason that I purchased a WinCE device over Palm was because of all the more fun hack potential.

Try looking at the Tcler's Wiki for a better solution to this.

The way comments work

the fact that error messages don't tell you a line number from a source file

Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here, and read about the system integrators here.

Don't like oil rigs? Well, it's highly unlikely that you can mod this post down without the Tcl that's built into practically every Cisco router on the planet. Read Cisco's tesimonial.

Once you've done that, go log off and watch TV. Oh yeah, did you know that the NBC network control system is a Tcl application? It is; it's been in the digital broadcast system from prototype all the way to full 24x7 operation. ComputerWorld ran an article about the project.

Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope

Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager.

I could go on all evening, this is just the tip of the proverbial iceberg.

Do you work with many programmers?

Yes.

All of them think they can do a better job,

Untrue. That statement works as a punchline for a comic strip, nothing more.

Sure, everyone occasionally feels he could do a better job than the implementer of some library he's using. The more "Freedom" he has to see and modify that library, the greater the chance that he'll either learn he was mistaken, or incrementally improve that library, rather than rebuilding it entirely.

if you let them.

That is a more specific problem- management that is insufficiently engaged, or insufficiently informed.

Back when that guy was proposing his idea, his boss should've made him explain why it was better than each of those alternatives.

However, had he been forced to justify the cost of a reinvention, his case would've been doubly strengthened because of the prevalence of proprietary software:

A) "We can't use those things, they are owned." Whether or not that's true in a particular case, people make those assumptions, and think less about reuse than the might. Even the TCL webpage doesn't explain that it's free to use on the first 2 layers of links.

B) "We shouldn't use those things, because then we wouldn't own our changes." "Hey boss, a proprietary scripting language, all our own- won't that be an asset for the corporation?". Many organizations put too much weight on the value of restricting their code. (And even if that is beneficial for those corporations, it might not be the best for the world at large)

A sampling of companies heavily reliant on Tcl can be seen at http://www.tcl.tk/customers/success/

The Tcler's Wiki is probably the hub of the most activity: http://mini.net/tcl/0

A brief list of cross-platform Starkits available is at http://mini.net/sdarchive/ though the Starkit system makes it trivially easy to package and distribute complete applications for multiple platforms. For an impressive display of what can be with a Tcl Starkit, you can check out Kitten, which is "a tclkit collection of [over 100] Tcl/Tk extensions aimed at reducing the work a developer has to do while developing a starkit. It contains script and compiled extensions like tcllib, BWidgets, expat, Expect, incr Widgets, mclistbox, mpexpr, narray, a tcl parser, an sgml parser, tclSOAP, stooop, Supertext, tdom, Tix, Tktable, tclXML, tkHtml, ClassyTk and others."

Understanding the value of the freedom that OSS gives to users is a good thing.

The next step should be to understand that they are free to program their computers.

Most computer users are good candidates for casual programming, but they have no idea how easy it is to write simple scripts to fit the needs of their daily tasks.

Make sure you include ActiveState Batteries Included distribution of Tcl/Tk and make sure that your users run the demos. It can be a revelation for them. It was for me.

--

Wouldn't it be great if some opensource calendaring program decided to call themselves iCal?

Actually, android lets you script fake keypresses, mouse events and such from a TCL interpreter (which expect happens to be). However, it doesn't let you see and check widget contents as text in the same way that many of the Windows-based test systems do. The commercial products for X suffer from similar failings when not using explicitly supported widget sets; as such, automated testing is just one of those things that isn't so well supported under X Windows. Hopefully Berlin (or some other successor) will help in this.

(FWIW, my job very recently involved buying or writing an automated test scaffold for graphical apps on Linux that would work across architectures and windowing systems -- it turned out that the latter was necessary, as the available commercial products just weren't/aren't cross-platform capable, and android has some serious faults which I'll expound on if asked. The product partially exists, having been put on hold for other internal development... perhaps when it's finished we'll release it under an open license).

I'm amazed that there is nothing here about Tcl. I use everything from shell to C to Perl, but Tcl is consistenly one of my favorite languages. I don't know why it doesn't get more respect.

Anyway, Activestate is a great place to start, especially the cookbook. The weekly Tcl-URL is published at Dr Dobbs. The Tcl Developer Xchange also has a lot of resources. Most of the major Tcl developers hang out in comp.lang.tcl (probably one of the most civil newsgroups there is). Quick answers to questions are always available there.