3 ms·
In terms of future ideas : Objects for multicore : I just don't buy it. The problem is that application concerns are orthogonal to implementation concerns and
by sgt101 6y ago
In terms of future ideas :
Objects for multicore : I just don't buy it. The problem is that application concerns are orthogonal to implementation concerns and the point of programming languages is to abstract the implementation concern away from the application programmer. The hardware engineers / os engineers should focus on providing transparent access to system resources. Application concerns just don't map onto resource consumption in my experience.
I found the articulation of mobility/cloud rather odd. I thought it was going to be about lambda (AWS) and cloud runner (GCP) and other cloud serverless offers (???) which encapsulate a collection of functionality and abstract the concerns of providing a callable interface and resources to run the functionality. Instead it outlined a scheme for failover and fault tolerance, which seems to rely on centralised naming and a global OS. I can't see that OO has much to do with serverless, and I can't see that it is really implicated in the failover story articulated here either. I would make similar comments about the section on reliability.
What is really strange is that the future of OO doesn't seem to be focused (according to this paper) on the concerns of maintainability, abstraction, readability and reuse that I think made it an attractive line for development in the past, and this is perhaps why it hasn't persisted as "the way and the only way" of software development into the current decade. I think that the community has dead-ended on these challenges and is now casting about for other stories to move forward on, which is basically the death-nell for this line of programming languages I think. I think this is probably because everyone knows that the four challenges I mention are extremely hard - even to define and more so to metricate, let alone solve - and those who take them on will be out published by folks working on virtually anything else. Also, sadly for comp sci, these are fuzzy, soft and human problems to do with people and organisations - and computer scientists scorn those who do not deal with bundles of cut and dried efficiency equations and derived bounds.
How to move forward - well I do have a plan. The way forward is to infiltrate all funding bodies and then strangle all the maths grants that are avoiding the rigor of pure math funding by pretending to be something to do with software development or AI. The freed up money can go to engineers solving problems that matter and the theory folks can go and justify their work to the funding programs that they should be justifying their work to. Until that happens I am afraid that I see no future for OO !
- andrekandre 6y agoisnt the actor model [0] by hewitt more akin to the "oo" that alan kay was talking about? im pretty sure its quite rigeriously defined in mathematical terms... am i perhaps missing something? [0] https://en.wikipedia.org/wiki/Actor_model_and_process_calculi https://en.wikipedia.org/wiki/Actor_model_and_process_calcul...