"How about Smalltalk as a basis or the foundation of what you want? If somebody pursues the approach, how hard would it be to develop a layer that takes care of the safe-unsafe issue?"
I don't feel like Smalltalk is going anywhere, so I don't know. Smalltalk has some great lessons, but I don't think well defined data access is one of them. Haskell, as mentioned earlier in this thread, has some pretty strong guarantees. Probably too strong ;)
I think something like the simple Scheme/Ruby convention that mutable methods have a ! would go a long way. You'd need more than a casual convention though, it would have to be a real promise. Though maybe if you had search agents rooting around in any method without a ! you'd see people apply that convention more thoroughly ;)
"On the other hand, if your concern crosses the single language barrier (you mention LINQ) then what sits at the top of Object Model A and Object Model B?"
FFI. That is, in any language you have an interface to access external things, so if that interface also includes information about the thing you are accessing then you have an opportunity to traverse into other systems. That's where the extensibility comes into play: you can't typically enumerate an external resource efficiently, but with appropriate interfaces maybe you could route the more high-level goal to that external resource.
That's a little handwavy, but...
'Regarding ZeroVM, I am a bit confused as to what exactly "moving apps to data means".'
I'd say two things. First, in the cloud context you can move a routine to another server. For instance consider `SELECT user FROM users WHERE confirmed_not_spammer(user)`: lets say confirmed_not_spammer() is not a database function, it's something pretty complex that you've implemented outside of the database context. Given portable processes it's at least imaginable that you could send just that routine to the database server, and it could call out to that function.
Actually that's both things! First, you send the routine to another computer, second you can have inversion of control: instead of sending a fully-baked query to another process, you leave open the possibility that the other process calls back as part of the process of finishing the query.
This is all also very hand-wavy. I expect there are still massive amounts of tooling necessary to fulfill the promise of ZeroVM.
"Given your prolific programming output (thank you for pip and virtualenv, big admirer) it is no wonder that you ponder these issues and wish to pursue something higher up. What I was trying to get at is that, respectfully, you are not the first and that there might be some lessons in the history of our profession that we could learn from and use as a basis for progress."
There are lots of corners of computing I don't know about, and I'm interested in hearing about them. But in these particular cases I am aware of the history. I think it's a little too easy to say "hey, someone already did this!" when really you mean "hey, someone made what you describe possible!" – but everything is possible, that's what Turing Complete means. Creating a viable and rich environment in which productive work can happen is different than creating a context in which you could create that environment.
Maybe someone, using Smalltalk, created a general object search and reasoning algorithm. I would in fact not be surprised if that did exist at one time, and I would be interested in learning about it. Similarly in Common Lisp, or even today in Clojure. Someone has even noted an example in Haskell. But the specific product is of interest to me, not just the environment that spawned it.
"massive amounts of tooling necessary to fulfill the promise of ZeroVM"
For sure. To me it seems like a good environment for isolating processes and users in security and execution contexts -- just boot up an instance, perform a task and then destroy. How it applies to data processing is not very clear.
"But the specific product is of interest to me, not just the environment that spawned it."
I see what you mean. I feel that anyone creating such a product/environment will run into massive problems that are very non-technical. How do you get language owners/implementers to agree to a common standard especially in today's web where we see common denominators of data sharing like RSS slowly being strangled by the big players -- let alone co-operations in programming environments/runtimes. The reason I mention the "big players" is that without somebody getting funded to think about this in a serious manner for an extended period of time, it will be very hard. Organisations like universities have the brainpower for this but not the money or the drive.
Something encouraging here is the recent slew of JVM languages -- they share objects with Java. Limitation here is its all on a single platform.
Maybe with the recent announcement of a Haskell kernel for IPython environment there is room for doing some inter-lang op work?
I don't feel like Smalltalk is going anywhere, so I don't know. Smalltalk has some great lessons, but I don't think well defined data access is one of them. Haskell, as mentioned earlier in this thread, has some pretty strong guarantees. Probably too strong ;)
I think something like the simple Scheme/Ruby convention that mutable methods have a ! would go a long way. You'd need more than a casual convention though, it would have to be a real promise. Though maybe if you had search agents rooting around in any method without a ! you'd see people apply that convention more thoroughly ;)
"On the other hand, if your concern crosses the single language barrier (you mention LINQ) then what sits at the top of Object Model A and Object Model B?"
FFI. That is, in any language you have an interface to access external things, so if that interface also includes information about the thing you are accessing then you have an opportunity to traverse into other systems. That's where the extensibility comes into play: you can't typically enumerate an external resource efficiently, but with appropriate interfaces maybe you could route the more high-level goal to that external resource.
That's a little handwavy, but...
'Regarding ZeroVM, I am a bit confused as to what exactly "moving apps to data means".'
I'd say two things. First, in the cloud context you can move a routine to another server. For instance consider `SELECT user FROM users WHERE confirmed_not_spammer(user)`: lets say confirmed_not_spammer() is not a database function, it's something pretty complex that you've implemented outside of the database context. Given portable processes it's at least imaginable that you could send just that routine to the database server, and it could call out to that function.
Actually that's both things! First, you send the routine to another computer, second you can have inversion of control: instead of sending a fully-baked query to another process, you leave open the possibility that the other process calls back as part of the process of finishing the query.
This is all also very hand-wavy. I expect there are still massive amounts of tooling necessary to fulfill the promise of ZeroVM.
"Given your prolific programming output (thank you for pip and virtualenv, big admirer) it is no wonder that you ponder these issues and wish to pursue something higher up. What I was trying to get at is that, respectfully, you are not the first and that there might be some lessons in the history of our profession that we could learn from and use as a basis for progress."
There are lots of corners of computing I don't know about, and I'm interested in hearing about them. But in these particular cases I am aware of the history. I think it's a little too easy to say "hey, someone already did this!" when really you mean "hey, someone made what you describe possible!" – but everything is possible, that's what Turing Complete means. Creating a viable and rich environment in which productive work can happen is different than creating a context in which you could create that environment.
Maybe someone, using Smalltalk, created a general object search and reasoning algorithm. I would in fact not be surprised if that did exist at one time, and I would be interested in learning about it. Similarly in Common Lisp, or even today in Clojure. Someone has even noted an example in Haskell. But the specific product is of interest to me, not just the environment that spawned it.