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