The Missing Principle Of Programming Languages

note-HXA7241-20090512T1748

Harrison Ainsworth

Support for data/computation mechanics (mostly known as performance evaluation/analysis)

The fundamental material of software is bits and their modification. This is determinate. And this makes software essentially engineering. A basic capability of physical, structural engineering is calculating resultant behaviour from forces across whole structures. In software this would be a matter of the time and space needed for transferring data, transforming data, and storing data. How much is the equivalent basic capability visible in software – understanding the performance of whole systems?

Common languages have no representation of time. They allow explicit control of space/storage, although total runtime needs are somewhat contingent. But where is time accounted for? There is no language equivalent. When this essential quantitative aspect seems non-existent in most software development, it is no surprise it seems less like engineering.

Time could be handled in two ways: where time properties are deduced for parts or whole, or where parts or whole must fit time properties. And these do indeed exist, but are marginal, specialist, in industry and academia. For the first way, there is ‘stochastic process algebras’: the main available tool is rather high-level: it can work from UML, but not from code (and might be limited to smaller inputs). For the second way, there are ‘synchronous languages’, such as: Lustre: in these, program modules react to, and fit into, a stream of event points.

Since compute power is plentiful, most everyday software is casual about performance. But for something so intrinsic to software engineering, at least some significant handling of data/computation mechanics would be reasonable in all languages.

References: