A discussion post to HPCWire: Retrofitting Programming Languages for a Parallel World
I have built toolkits and frameworks in various environments, so I became a passionate "framework-maker".
I concluded that languages already know too much, and they should return to what they are created for: be the most readable form of algorithms(!) for human eye.
The "rest": the structure of data and service components, the deployment (choose and set up a component instance to do a certain service) and the implementation (compiled binaries to respond to messages) should NOT be part of (any) programming language or toolkit, but a set of declarations that the current runtime can understand.
This is because the hardware became very fast and smart, but it can help us only if it KNOWS the structure of our approach. This is lost with compilation.
From another point of view: the core problem with these languages is the '.', the dot: it shows that
1: our logical concept of the solution is buried into a programming language
2: we call functions of the components directly
3: we access their data (memory) directly.
All are fundamentally wrong.
1: We have myriads of languages and tools - and the same, quite small set of tasks. Our solutions should be independent from them.
2: ... so nasty things appear like proxy objects, dll hell, etc.
3: ... the swamp of proxies and locking issues.
My answer is framework-level
- types,
- API to access data
- messages to components.
I hope you don't mind "advertising" my personal experiment here:
What is programming?
How we should write software?
