In fact, one of the big things about this class of languages is that the program exists in a file which is then interpreted in sequence, one might say _serially_. Expressions are executed as they are encountered, Functions are created on the fly, and Objects are 'opened' and updated as the file is consumed.
And so I propose calling this kind of language a 'serial' language.
Once I've named it like this it makes me think about other languages, and how to contrast/compare when considered in this way.
'Normal' languages such as C and Java and so on are all compiled. So while expressions are executed as they are encountered, the way they are encountered is determined by a predefined structure of objects and structs and functions. These languages are typically less dynamic, because they don't have to be; there is no requirement that classes be defined on the fly because they can be created at compile time.
The final group of languages on this spectrum are those that exist within an Image, such as SmallTalk and Self. Here the objects and functions are constructed, essentially by hand, and then exist within the image. There is no need to compile or serially create them ever again.
Why is this a spectrum - for one reason, and that is the degree to which the structure (not behaviour) of the program is executed at runtime. Ie, how much processing happens before the program is ready to actually do what it was written to do. Serial languages create all structure at runtime. Compiled languages create classes at compile time, but require things like DI (eg Spring) to build up the structure of relationships between these constructs. Image based environments have no processing necessary before the program starts; all objects and their relationships have been defined and stored within the Image.
This then leads to another thing to think about; if Image based environments require so much less code to setup them up, does this mean that they are better because 'every line of code is a liability?'
No comments:
Post a Comment