Features de-featurized or "plutoed" from the Mynx programming language
I've finished the Mynx book, but in revising the Mynx language manual, I noted some features as I've been implementing the checks for the semantic analyzer in the compiler.
Some features of Mynx are "creeping featuritis" and need to plutoed or de-featurized.
It struck me that I was "over-building" Mynx as a programming language, forecasting problems and putting in a feature in anticipation -- instead of a language feature to write software.
In the immortal words of Homer Simpson... "doh!"
The over-built features of Mynx were:
Each feature had its specific intent for its inclusion, but more compelling reasons indicated the need for exclusion -- problem prevention, not software creation.
Using a metaphor a programming language is a palette of concepts and abstractions for a software developer's mind to use to paint a canvas in software.
Over-built features are trying to avoid mixing hot pink with foghorn gray by
providing a feature of foghorn pink instead.
This exercise in create, analyze, remove has emphasized the need for conceptual simplicity in a programming language. Not simplicity in fewer statements or keywords, but concepts and how well they mesh together into a cohesive whole.
Fred Brooks in the book "The Mythical Man Month" wrote about "conceptual integrity" and stated "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation."
More simply (for what its Wirth...err, worth...) Niklaus Wirth said when you add things to a language, throw away other things.
In the case of Mynx, as the language designer, I added complexity in the form of features to prevent possible problems, rather than focusing on the features for utility. Experience is the best teacher, one of the reasons I embarked on creating and implementing a new programming language.
Some features of Mynx are "creeping featuritis" and need to plutoed or de-featurized.
It struck me that I was "over-building" Mynx as a programming language, forecasting problems and putting in a feature in anticipation -- instead of a language feature to write software.
In the immortal words of Homer Simpson... "doh!"
The over-built features of Mynx were:
- 'self' as an abstract, but implicit runtime type of a class.
- accessors to access class attributes.
- abstract methods in generic classes.
- 'own' as static method in a virtual class.
Each feature had its specific intent for its inclusion, but more compelling reasons indicated the need for exclusion -- problem prevention, not software creation.
Using a metaphor a programming language is a palette of concepts and abstractions for a software developer's mind to use to paint a canvas in software.
Over-built features are trying to avoid mixing hot pink with foghorn gray by
providing a feature of foghorn pink instead.
This exercise in create, analyze, remove has emphasized the need for conceptual simplicity in a programming language. Not simplicity in fewer statements or keywords, but concepts and how well they mesh together into a cohesive whole.
Fred Brooks in the book "The Mythical Man Month" wrote about "conceptual integrity" and stated "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation."
More simply (for what its Wirth...err, worth...) Niklaus Wirth said when you add things to a language, throw away other things.
In the case of Mynx, as the language designer, I added complexity in the form of features to prevent possible problems, rather than focusing on the features for utility. Experience is the best teacher, one of the reasons I embarked on creating and implementing a new programming language.
Labels: conceptual integrity, mynx, mynx book, plutoed
posted by Will Gilreath at
1:32 AM
<< Home