Difference between revisions of "General software issues"
(→What is absolutely not a necessity but could boost development speed) |
m (→What is likely to be a necessity) |
||
| Line 71: | Line 71: | ||
* reversible computing | * reversible computing | ||
Deleting data produces heat proportional to the operation temperature. In super high density computing this needs to be avoided. | Deleting data produces heat proportional to the operation temperature. In super high density computing this needs to be avoided. | ||
| + | |||
| + | [https://en.wikipedia.org/wiki/Janus_%28programming_language%29#Time-reversible_Computing time-reversible computing low level programming language] <br> High level programming language that match reversible computing best are functional programming languages like Liasp and Haskell. | ||
== What is absolutely not a necessity but could boost development speed == | == What is absolutely not a necessity but could boost development speed == | ||
Revision as of 14:26, 31 July 2015
In a world where the digital and physical realm starts to blend that is physical products become networked live acutateable and reconfigurable software architecture / organisation / design or however one may call it becomes even more important than it is already today.
Key issues are:
- stability (at best error-proofness) correctness; research in Haskell
- maintainability
- extendability
- modularity
- diversity (as options for unexpected dead end routes)
- optimized-specialisation conserving functionality-expanding-generalisation and vice versa
- highly complex version management (dependency hell)
- ...
Contents
File systems
Currently used tree based and machine local file systems have their limits. Sorting the same data after multiple hierarchical criteria is impossible. To give an example: Assume one owns a lot of image-file text-file sets. The small text files are of high importance (e.g. source code) while the huge images are of relatively low importance (e.g. rendered from source). Archiving different backup levels (location, redundancy level) for file types of different importance isn't possible with the basic functionalities of tree based file systems.
File system indexing usage of meta-data and file tagging only mend but do not solve the problem. Some kind of graph based file systems are needed. Graph databases (like Neo4j?) are interesting but are only crutches if implemented on top of tree based file systems.
The limitation to serial access to mass storage disk space (now changing with random access SD drives) led to the fact that current systems are still hardware near programmed and suffer from a lack of abstraction. Data must be manually serialized for persistent storage. Net based services like Google drive and Facebook already emulate this behavior. Another interesting "on top" approach is yesod with its integrated persistence.
- A good writeup about the problem and solution approaches can be found here: file system alternatives
- Another pretty good writeup of why file systems in tree structure are fundamentally flawed: "File Systems and Usability – the Missing Link" by Robert Freund
- [todo: add link to NHFS paper]
Recently Google made a move in this direction. Google drive allows to create folder structures as an directed acyclic graph!
Dependency hell
Current packet management systems suffer from the dreaded problem of dependency hell. Especially developers who install a lot of software packages in parallel are affected. Solution approaches include:
- Packet manager of experimental NixOS - review
- multi-platform reversible java package management system
Avoiding hidden state (a potential source of errors) can be compatible with interactive environments:
- Tangible functional programming YT Video (Eros demo program; TVs ... Tangible Variables)
- Wikipedia: Functional reactive programming; research of Conal Elliott
- House - functional operating system
- reversible data processing
- Replacing softwary with "hardcoded hardware" to make to make things that are not supposed to happen impossible. Self limitation for safety
- instability of high level operating systems ...
- Debugging
CAD software
[Todo ...]
From Tom's machine phase blog comes an exampel of the usage of Nanoengineer-1:
DNA origami: from design to product
Bad software design may undermine the "Disaster proof" property of globally used APM.
Relation of AP Technology to new computing paradigms
What is likely to be a necessity
- reversible computing
Deleting data produces heat proportional to the operation temperature. In super high density computing this needs to be avoided.
time-reversible computing low level programming language
High level programming language that match reversible computing best are functional programming languages like Liasp and Haskell.
What is absolutely not a necessity but could boost development speed
Widely known:
- quantum computing (depends on reversible design)
- neural network compution (deep learning)
Barely known:
- memcomputers (interspersed comuting and memory can increase performance for certain algorithms)
Memcomputing NP-complete problems in polynomial time using polynomial resources and collective states - lambda machines / graph reduction machines (wikipedia) (historic alternative to Von Neumann architecture computers)
Research 2015: Reduceron webpage github implemented on FPGAs
Also maybe of interest:
- ternary (mechanical) logic - higher radix efficiency but worse in transporting carries - (wikipedia)
- digital usage of analog mechanical computing mechanisms (a few bit at a time) - link
Applications
Alternative computing architectures that boost certain types of problems can often be used for optimization:
- circutry; layout;
- optimal molecular topologies for bigger structural crystolecules e.g. brackets (aka Kaehler-brackets); ...
