I've been following this thread for a few days now, and I'd like to contribute my $0.02. The original problem statement asserted several presumptions: I think a number of people were duped by these presumptions into focusing on the longevity of the language. To me, having seen many good things come and go, I would not speculate on the longevity of anything that we could conclude might have permanence. Many languages have appeared to be "the answer for all time" only to fade into obscurity, not for lack of good qualities, but because of the money behind some other language's marketing department and the heat of passion for the new stuff in the buyer's pockets. But in the stated problem there are larger issues that have mostly gone by without discussion. Given the original problem statement, I would have to ask: - If the app is not "controlling the process itself", then what is it controlling? Given that the process varies per customer but the app does not control the process itself, then I'm going to hypothesize that the app controls information about the process, such as variations in a manufacturer's process "recipe". For example, the process produces a commodity such as gasoline, and different customers each purchase their own formulation. If the output is a custom formulation, then, after any number-crunching, the app could produce a very simple text document. Would such an application require the power of FORTRAN or C? If the I/O is mostly for data entry and display, then couldn't a raw Access databse suffice? At the very least, the data could be more easily forwarded to a newer environment than custom code. - Will the application run on a general-purpose computer or on a specific architecture? If general purpose, then survivabilty of the language (its development and operational environments) would be of primary concern. If on a specific architecture, it would make sense to write it in the machine language of that platform, provided it was fully documented with specs and functional comments. - Is the manufacturing process expected to persist without significant changes for the 30 years? If so, the app could be burned into a stable media (PROM, EEPROM, or the like). But if it would be subject to significant changes, perhaps better to maintain source and compiled versions. Having run a factory for 6 years, I understand the desire for a solution that can be created and left alone. But 20 other years in business and in systems, I know that things change, and often when least convenient and most costly to rectify. It is a good goal to want a system that will run unaltered and survive for 30 years. But will the business still be in business then? Or will the industry have changed, the need for the product in the marketplace have changed, the machinery or degree of meeting customer variation have all gone away? I think the solution to this problem does not lie in having "one right answer", but in having a data-forwarding strategy that is flexible, responsive, updatable, and maintainable. It would be better to change the app several times in the 30 years with reasonable costs than to bet on one solution that could be broken a few short years later. Just depends on what's at risk and how much of a gambler you are... So, I hope that's some food for thought... -John M. Montclair, NJ