Site Menu Project Specification Implementation Recommendations Reference Needs Updating Work in Progress Wastebasket Wiki Manual |
GoalsProject.Goals HistoryHide minor edits - Show changes to markup 2015-09-20 11:56
by -
Changed line 43 from:
to:
2015-09-20 11:53
by -
Changed line 14 from:
to:
2015-09-19 15:48
by -
Changed line 23 from:
to:
2015-09-19 15:46
by -
Added line 23:
Changed line 25 from:
to:
2015-09-18 10:42
by -
Changed line 40 from:
to:
2015-09-18 10:40
by -
Changed line 40 from:
to:
2015-09-18 10:40
by -
Added line 40:
2015-09-18 10:37
by -
Changed lines 34-39 from:
to:
Long Term Outlook
2015-09-18 10:29
by -
Added lines 12-18:
Administrative Deliverables
2015-09-18 10:06
by -
Changed line 16 from:
to:
2015-09-18 10:05
by -
Changed lines 13-14 from:
Deliverablesto:
Documentation DeliverablesDeleted lines 15-16:
Added lines 17-22:
Software Deliverables
Changed line 27 from:
to:
2015-09-18 10:01
by -
Added lines 12-24:
Deliverables
2015-09-18 09:50
by -
Changed line 9 from:
First, to offer a solution to the problem of unsafe and unreliable software through the design, implementation and provision of a safe and literate software development environment, free of charge, along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in software production. to:
First, to offer a solution to the problem of unsafe and unreliable software through the design, implementation and provision of a safe and literate software development environment, free of charge under a permissive open source license, along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in software production. 2015-09-18 09:47
by -
Changed lines 7-11 from:
Our mission is to make information technology safe and reliable by providing the design and implementation of a safe and literate software development environment free of charge along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in the realm of software development in particular and information technology in general. to:
Our mission is to make future software safe and reliable. To achieve our mission, our aim is two-fold: First, to offer a solution to the problem of unsafe and unreliable software through the design, implementation and provision of a safe and literate software development environment, free of charge, along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in software production. Second, to educate the general public about the dangers of the prevailing software production model and how it proliferates information security issues by creating vulnerabilities faster than can be identified, let alone fixed and how our solution can help solve the problem at its root cause by changing attitudes and practises. 2015-09-18 09:32
by -
Changed line 3 from:
Our vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, professionals who do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost. to:
Our vision is that of a future where we will be able to go online without concern that we might become victims of theft, sabotage or vandalism; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, professionals who do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost. 2015-09-18 09:30
by -
Changed line 3 from:
Our vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, where they do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost. to:
Our vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, professionals who do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost. 2015-09-18 09:29
by -
Changed lines 1-18 from:
Design Goals
Feature Omission GuidelinesIn the context of modern programming practise, if we found the omission of a feature to be reasonable and justified then we considered its removal. Conversely, if we found its omission to to be unreasonable and unjustified then we rejected its removal. We aimed to avoid oversimplification. Feature Addition GuidelinesWe considered a new feature for adoption if a clear need could be demonstrated and if we found it to be reasonable and consistent with the overall design philosophy. We put a particular emphasis on suitability for systems implementation and systems programming as well as interfacing to C. We aimed for the ability to replace C as a systems implementation language. When considering the addition of a feature, we looked at in the context of the weight of the entirety of features, not in isolation. We observed an imaginary baggage allowance, whereby items had to be removed to make space for others to be added. Our aim was to avoid feature creep. Backwards Compatibility GuidelinesIf a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and consequently we removed it without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features. to:
VisionOur vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, where they do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost. MissionOur mission is to make information technology safe and reliable by providing the design and implementation of a safe and literate software development environment free of charge along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in the realm of software development in particular and information technology in general. 2015-09-14 07:38
by -
Changed line 3 from:
to:
Changed lines 10-11 from:
In the context of modern programming practise, if the omission of a feature is found to be reasonable and justified it should be considered, if its omission is found to be unreasonable and unjustified it should be rejected. Oversimplification is to be avoided. to:
In the context of modern programming practise, if we found the omission of a feature to be reasonable and justified then we considered its removal. Conversely, if we found its omission to to be unreasonable and unjustified then we rejected its removal. We aimed to avoid oversimplification. Changed lines 13-16 from:
A new feature may be considered for adoption if a clear need can be demonstrated and if it is found to be reasonable and consistent with the minimalist design philosophy. Particular emphasis should be on suitability for systems implementation and systems programming as well as interfacing to C. When considering the addition of a feature, it must be looked at in the context of the weight of the entirety of features, not in isolation. An imaginary baggage allowance should be observed, items may have to be removed to make space for others to be added. Feature creep is to be avoided. to:
We considered a new feature for adoption if a clear need could be demonstrated and if we found it to be reasonable and consistent with the overall design philosophy. We put a particular emphasis on suitability for systems implementation and systems programming as well as interfacing to C. We aimed for the ability to replace C as a systems implementation language. When considering the addition of a feature, we looked at in the context of the weight of the entirety of features, not in isolation. We observed an imaginary baggage allowance, whereby items had to be removed to make space for others to be added. Our aim was to avoid feature creep. Changed line 18 from:
If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and it must be removed without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features. to:
If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and consequently we removed it without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features. |