The simulation tool I have developed over the past couple of years, is written in C++ and currently has a tcl interpreted front-end. It was written such that it can be run either in an interactive shell, or by passing an input file. Either way, the input file is written in tcl (with many additional simulation-specific commands I have added). This allows for quite powerful input files (e.g.- when running monte-carlo sims, random distributions can be programmed as tcl procedures directly in the input file).
Unfortunately, I am finding that the tcl interpreter is becoming somewhat limited compared to what more modern interpreted languages have to offer, and its syntax seems a bit arcane. Since the computational engine was written as a library with a c-compatible API, it should be straightforward to write alternative front-ends, and I am thinking of moving to a new interpreter, however I am having a bit of a time choosing (mostly because I don't have significant experience with many interpreted languages). The options I have begun to explore are as follows:
Remaining with tcl:
Pros:
- No need to change the existing code.
- Existing input files stay the same. (though I'd probably keep the tcl front end as an option)
- Mature language with lots of community support.
Cons:
- Feeling limited by the language syntax.
- Getting complaints from users as to the difficulty of learning tcl.
Python:
Pros:
- Modern interpreter, known to be quite efficient.
- Large, active community.
- Well known scientific and mathematical modules, such as scipy.
- Commonly used in the academic Scientific/engineering community (typical users of my code)
Cons:
- I've never used it and thus would take time to learn the language (this is also a pro, as I've been meaning to learn python for quite some time)
- Strict formatting of the input files (indentation, etc..)
Matlab:
Pros:
- Very power and widely used mathematical tool
- Powerful built-in visualization/plotting.
- Extensible, through community submitted code, as well as commercial toolboxes.
- Many in science/engineering academia is familiar with and comfortable with matlab.
Cons:
- Can not distribute as an executable- would need to be an add-on/toolbox.
- Would require (?) the matlab compiler (which is pricy).
- Requires Matlab, which is also pricy.
These pros and cons are what I've been able to come up with, though I have very little experience with interpreted languages in general. I'd love to hear any thoughts on both the interpreters I've proposed here, if these pros/cons listed are legitimate, and any other interpreters I haven't thought of (e.g.- would php be appropriate for something like this? lua?). First hand experience with embedding an interpreter in your code is definitely a plus!
I was a strong Tcl/Tk proponent from pre-release, until I did a largish project with it and found how unmaintainable it is. Unfortunately, since prototypes are so easy in Tcl, you wind up with "one-off" scripts taking on lives of their own.
Having adopted Python in the last few months, I'm finding it to be all that Tcl promised and a whole lot more. As many a Python veteran can tell you, source indentation is a bother for the first hour at most and then it seems not a hindrance but affirmatively helpful. Incidentally Tcl's author, John Ousterhout was alternately praised and panned for writing a language that forced the One True Brace Style on Tcl coders (I was 1TBS so it was fine by me).
The only Tcl constructs that aren't handled well by Python are arbitrary eval "${prefix}${command} arg" constructs that shouldn't be used in Tcl anyway but are and the uplevel type statements (which were a nice idea but made for some hairy code). Indeed, Python feels a little antagonistic to dynamic eval but I think that is a Good Thing. Unfortunately, I've yet to come along with a language that embraced its GUI as well as Tcl/Tk; Tkinter does the job in Python but it hurts.
I cannot speak to Matlab at all.
With a few months of Python under my belt, I'd almost certainly port any Tcl program that is in ongoing development to Python for purposes of sanity.
Have you considered using Octave? From what I gather, it is nearly a drop-in replacement for much of matlab. This might allow you to support matlab for those who have it, and a free alternative for those who don't. Since the "meat" of your program appears to be written in another language, the performance considerations seem to be not as important as providing an environment that has: plotting and visualization capabilities, is cross-platform, has a big user base, and in a language that nearly everyone in academia and/or involved with modelling fluid flow probably already knows. Matlab/Octave can potentially have all of those.
Well, unless there are any other suggestions, the final answer I have arrived at is to go with Python.
I seriously considered matlab/octave, but when reading the octave API and matlab API, they are different enough that I'd need to build separate interfaces for each (or get very creative with macros). With python I end up with a single, easier to maintain codebase for the front end, and it is used by just about everyone we know. Thanks for the tips/feedback everyone!
来源：https://stackoverflow.com/questions/3167661/picking-a-front-end-interpreter-for-a-scientific-code