OT: Language for the ages

Jules Richardson julesrichardsonuk at yahoo.co.uk
Fri Oct 14 15:35:00 CDT 2005


Patrick Finnegan wrote:
> Jules Richardson declared on Friday 14 October 2005 01:41 pm:
> 
>>Chuck Guzis wrote:
>>
>>>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
>>>obsolesence, 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.
>>
>>Or Java; at least it's standard, strictly defined, open (in that
>>bytecode format etc. is documented), cross-platform, and even if it
>>*were* to become obsolete in x years I can't see there not being
>>emulators around on current hardware of the day which can emulate a
>>DOS / Windows / whatever box and therefore run the compiler or
>>runtime.
> 
> 
> Except that the program you write against today's Java won't compile 
> against tomorrow's Java.
> 
> It's amazing to me that a language API can change that much between point 
> revisions (eg, 1.1 to 1.2).

Not really; the main changes are always going to be in the GUI - and 
that's probably true for any language. Pick a cross-platform GUI layer 
for any programming language of today and it's probably going to change 
over the 30 year timescale mentioned.  In the Java world, all of the 
basic language structures and I/O libraries are very stable (I'm 
ignoring the 1.02 to 1.x transition as that really was almost a beta to 
public release step). Eye-candy stuff's always going to be at the mercy 
of current trends, unfortunately.

Someone else brought up the character-based UI, and I'd say that's a 
very good bet for survival if the 30 year timescale is one of the most 
important goals. I'd probably either have a text-mode interface to the 
Java code, or better still stick a bit of networking code in there so 
that I could just control it from any old telnet client (or open up the 
possibility of control via whatever scripting language or web technology 
or GUI utility is current flavour of the month)

At the end of the day, the types of server / control apps that seem to 
be lasting the longest are those with well-designed low-level interfaces 
  onto which higher-level control applications can be bolted (without 
compromising the central core app of course)

Of course trying to convince the average manager of the benefit in using 
simple character-based UIs for anything can be easier said than done... 
but I'd probably aim for a Java app with a simple textmode UI and 
network interface built in (regardless of whether it ended up being 
compiled to native code or interpreted bytecode on the current target 
platform; that's irrelevant). Make sure the network interface is (very) 
well documented and versioned just in case unforseen enhancements have 
to be added in ten years down the line...

cheers

Jules


More information about the cctalk mailing list