Languages Of The Future
Matthew Tuck
matty@box.net.au
Mon, 02 Nov 1998 22:21:48 +1030
OK, sorry for the delay, I've been a bit busy, but hope to get some more time to talk about things. I'm going to start dumping my ideas on the project. What will become of them I don't know, but I've got notepads worth of writing.
I've decided to start with some of the ideas I believe will be shaping languages of the future. This is just what I can think of at the moment.
* Intelligent Editors
The text editing of programs has been with us for way too long. It is time to make truly intelligent editors - things that do what you want to do easily. Integrated environments, syntax highlighting, bracket matching, outlining, auto indenting, etc. are all useful starts but there is only so much you can do with text. Smalltalk is an example of a graphical environment, although I'm not sure to what extent it goes.
Working on parse trees, offers among other things:
o Separation of syntax from the language. You can have multiple syntaxes for different users, and when a user takes a program from another user, it appears according to local preferences. Internationalisation of grammar or even different forms of editing are possible.
o Enhanced Modifiability. For example, if you change a variable name, the editor can automatically change all references to it.
o Enhanced Navigation. Hyperlinking of identifiers, removing unwanted details, etc.
* Large Libraries
Large libraries dramatically increase reuse and prevent reinventing the wheel. Java is an example of this. In addition, once the libraries get large, there is a necessity to generalise and simplify, using higher order routines for example, which results in even more functionality. Using and supporting design patterns will also help.
* Object Oriented Theory
Object orientation has been around for a while, but there is still a long way to go.
o Total solutions to the problems of multiple inheritance need to be found.
o Languages should reduce the reliance on built in types to the minimal amount. All of these types should be on par with library defined types. Arrays are a good example of something that has no reason to be built in.
o All types should be able to have multiple implementations specified.
o Covariance needs to be supported in a simple way.
o The implementation hiding problems of public variables need to be removed while still allowing the syntactic convenience of declaring variables rather than access methods.
o A full separation of the ideas of specification and implementation allows excellent
flexibility in writing, reusing and modifying.
--
Matthew Tuck - Software Developer & All-Round Nice Guy
***
Check out the Ultra programming language project!
http://www.box.net.au/~matty/ultra/