The systematic study of methods for producing high quality software. Your comment is equivalent to calling a flexural test machine 'materials engineering'.
Granted. I'll throw out the cloud platform, but keep the others.
1) There is no substitute for the relational model. Clearly it is a paradigm for building mathematical objects.
2) I didn't strongly advocate my choice of F#. Strongly-typed, functional first, ML syntax language is the sweet spot today. In theory this predicts faster development and fewer bugs. All software assemblies are mathematical objects, those built with strongly-typed, functional languages tend to be more humanly comprehendible.
3) No estimates allows practitioners to make useful projections of the course of a project. (Of the 4, this one has the weakest claim to belong to theory, yet I will argue useful projections are a kind of prediction.)
4) TLA+, or something like it, separates spec from implementation detail and makes "predictions" (at arbitrary level of granularity) of what a completed software component will do.
jackfoxy|8 years ago
1) There is no substitute for the relational model. Clearly it is a paradigm for building mathematical objects.
2) I didn't strongly advocate my choice of F#. Strongly-typed, functional first, ML syntax language is the sweet spot today. In theory this predicts faster development and fewer bugs. All software assemblies are mathematical objects, those built with strongly-typed, functional languages tend to be more humanly comprehendible.
3) No estimates allows practitioners to make useful projections of the course of a project. (Of the 4, this one has the weakest claim to belong to theory, yet I will argue useful projections are a kind of prediction.)
4) TLA+, or something like it, separates spec from implementation detail and makes "predictions" (at arbitrary level of granularity) of what a completed software component will do.
verall|8 years ago