4 ms·

Assuming your concern is across a single/uniform language: How about Smalltalk as a basis or the foundation of what you want? If somebody pursues the approach,

Assuming your concern is across a single/uniform language: 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? MOP: extensibility without ubiquitous useful patterns. My experience says that "ubiquitous patterns" manifest when you use a technology against real problems. So use the MOP to tackle several problems and then watch the patterns emerge. If 1/25th of the raw brain power had been applied to abominations like PHP had been diverted to using Lisp and exploring the meta patterns in there.... my gut says your blog post would have been about some cool framework you wrote to solve the problem ;) 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? It is some Meta Model or a specific library framework that understands both. Back to the meta again, back to all those leaves on a branch of history left unexplored. What do we have instead? Brainpower, time, money and youth/a generation being devoted to the "hip hop VM" at Facebook. 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. Regarding ZeroVM, I am a bit confused as to what exactly "moving apps to data means". If I have a 20 GB log file to process living on a filesystem, how do I "move" my Python processor script to it?

ianbicking 13y ago
"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.
- vithlani 13y ago
  "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?

ianbicking 13y ago

"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.

vithlani 13y ago
"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?