OT: Language for the ages

[infomagic]

> Here's an interesting problem.
> 
> Suppose you wanted to write an application for a 
> manufacturing process that will, in all probability, run for 
> the next 30 years.  No direct control of the process itself 
> is entailed (i.e., you don't need the program to operation 
> valves or run motors), but you do need this program to 
> compute manufacturing parameters for each customer.  I/O 
> requirements are very modest, mostly simple keyboard and display.
> 
> What would you write it in?  Clearly, you'd want to be 
> independent of a particular software vendor, so the likes of 
> Visual BASIC isn't an option.
> You'd also want to write in a language that isn't nearing 
> obsolescence, nor one that's still evolving.  "Niche" 
> languages would be out of the question, as longevity could be 
> a problem.
> 
> So what would it be?   My vote is for FORTRAN.



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: 
>you'd want to be 
> independent of a particular software vendor..
>...
> You'd also want to write in a language that isn't nearing 
> obsolescence, nor one that's still evolving.  "Niche" 
> languages would be out of the question, as longevity could be 
> a problem.


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