Alee - thanks for your comments. I agree that 1) all those “old” models (or at least, some of them) should hav a pathway for being utilized in a modern framework, 2) “integronsters” (good term!) should be avoided where possible, and 3) multilanguage support is helpful (and relevant to (1)). We made a vary conscious choice to write Envision in C++, in significant part because of the need to allow plug-ins written in various languages to be incorporated into an Envision application, and C++ is about as close to a universal “glue” language out there. We have in fact written plugins for Envision in FORTRAN, Python, and Java, usually with a little C++ code in the middle to take care of any language-specific needs. This, coupled with performance and a robust object-orientation make C++ a good language, in our opinion, for the “under the hood” part of an application, where efficiency, representation power, and flexibility are arguably more important than ease of use. We think of this is a layered process: 1) a high-performance “kernel” providing the core functionality and plumbing (C++ is great for this), possibly a GUI layer (written in whatever is easiest), and the plug-ins, which come in two flavors - what we call “standard” plug-ins" that can be used with no coding (just a configuration file) and “custom” plugins, that we generally write in C++. As we (and others) develop more and more “standard” plugins that can be configured in pretty accessible ways (e.g. xml files), the need for custom plugins lessons - that’s really where we see alot of the Envision development work going now - creating an improving the standard plugins for creating a wider and wider variety of models. But, you’ve got to have a robust framework to start with, which is where Envision comes in.
One comment on the “million lines of code” perspective. Envision consist of two parts, an “Engine” which has no GUI and is OS-independent, but provides the core under-the-hood functionality and exposes a bunch of capabilities to plugins, and the Window GUI front end. As is typical, the GUI is responsible for the large majority of the code in Envision. The Engine is considerable smaller.
Regarding accessing our SVN repository for the source code - we just made some changes that hadn’t yet been pushed to the Envision website, but that has now been updated. You will find a link to our SVN site under the “Overview” menu. I agree that Git is probably a better solution - we are planning to migrate at some point reasonably soon, but that hasn’t quite made it up to the top of the priority list yet.