Mobile Lua - coming on strong

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Mobile Lua - coming on strong

Stefan Reich
Hi earthlings =)

OK, so I want to get very serious with this Mobile Lua idea now.

The execution core works. Hyperjumps work. Admin interface is functional too. (All in the next release.)

So it is time for some heavy duty marketing.

Here's what I know:

I know that the Mobile Lua concept is both innovative and sound; I know that the applications are boundless; and I pretty darn sure know that it is going to catch on pretty quickly.

What I am now looking for is a way to convince people of the advantages of code mobility.

Maybe you guys can help me out a little here.

For starters, I took a look at the list of the most popular programming languages and checked if they offer mobility. Here's the result (most popular languages listed first):

Language       Mobility
-------------------------
C              not mobile
Java           only in browser; not transitive
C++            not mobile
PHP            not mobile
JavaScript     only in browser; not transitive
Python         not mobile
C#             not mobile
Perl           not mobile
SQL            not mobile
Ruby           not mobile
Shell          not mobile
Visual Basic   only in browser (VBS); not transitive
Assembly       not mobile
ActionScript   only in browser; not transitive
Objective C    not mobile
Lisp           not mobile
Delphi         not mobile
Pascal         not mobile
Scheme         not mobile
Haskell        not mobile
Tcl            not mobile
Fortran        not mobile
Ada            not mobile
Lua            full transitive mobility (as Mobile Lua)

"Mobility", here, is defined as the ability of any program to move to another computer at any time while preserving its full inner state (code+data+threads). (Outside connections, naturally, may have to be recreated after moving.)

"Transitive mobility", then, is defined as the ability to move between computers more than once per script invocation.

(Note: There may be mobile agent frameworks for multiple languages listed above; but if they exist, they don't seem to be in widespread use. So it seems they are either too complicated, too heavy-weight or not practically usable for other reasons. I am very open for counterexamples if there are any!)

So it seems that Lua, with the advent of Mobile Lua, is now the only popular language offering full code mobility.

Question is: Are people aware of the advantages of code mobility? Are you aware? If not, what would it need for you to understand these advantages?

I have different ideas on how to demonstrate the possibilities of a mobile Lua - but I thought I'd check with you guys first to see if you have anything to say on this. I really hope that this list will prove a positive place and not one of "I want to criticize so I can bring you down".

-- Stefan

PS: Of course, the primary question for any new technology always is: Can it do porn? =) (I'll leave the answer to the readers, for now. =)
Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Josh Simmons
On Tue, Nov 15, 2011 at 11:05 AM, Stefan Reich
<[hidden email]> wrote:

> Hi earthlings =)
>
> OK, so I want to get very serious with this Mobile Lua idea now.
>
> The execution core works. Hyperjumps work. Admin interface is functional
> too. (All in the next release.)
>
> So it is time for some heavy duty marketing.
>
> Here's what I know:
>
> I know that the Mobile Lua concept is both innovative and sound; I know that
> the applications are boundless; and I pretty darn sure know that it is going
> to catch on pretty quickly.
>
> What I am now looking for is a way to convince people of the advantages of
> code mobility.
>
> Maybe you guys can help me out a little here.
>
> For starters, I took a look at the list of the most popular programming
> languages and checked if they offer mobility. Here's the result (most
> popular languages listed first):
>
> Language       Mobility
> -------------------------
> C              not mobile
> Java           only in browser; not transitive
> C++            not mobile
> PHP            not mobile
> JavaScript     only in browser; not transitive
> Python         not mobile
> C#             not mobile
> Perl           not mobile
> SQL            not mobile
> Ruby           not mobile
> Shell          not mobile
> Visual Basic   only in browser (VBS); not transitive
> Assembly       not mobile
> ActionScript   only in browser; not transitive
> Objective C    not mobile
> Lisp           not mobile
> Delphi         not mobile
> Pascal         not mobile
> Scheme         not mobile
> Haskell        not mobile
> Tcl            not mobile
> Fortran        not mobile
> Ada            not mobile
> Lua            full transitive mobility (as Mobile Lua)
>
> "Mobility", here, is defined as the ability of any program to move to
> another computer at any time while preserving its full inner state
> (code+data+threads). (Outside connections, naturally, may have to be
> recreated after moving.)
>
> "Transitive mobility", then, is defined as the ability to move between
> computers more than once per script invocation.
>
> (Note: There may be mobile agent frameworks for multiple languages listed
> above; but if they exist, they don't seem to be in widespread use. So it
> seems they are either too complicated, too heavy-weight or not practically
> usable for other reasons. I am very open for counterexamples if there are
> any!)
>
> So it seems that Lua, with the advent of Mobile Lua, is now the only popular
> language offering full code mobility.
>
> Question is: Are people aware of the advantages of code mobility? Are you
> aware? If not, what would it need for you to understand these advantages?
>
> I have different ideas on how to demonstrate the possibilities of a mobile
> Lua - but I thought I'd check with you guys first to see if you have
> anything to say on this. I really hope that this list will prove a positive
> place and not one of "I want to criticize so I can bring you down".
>
> -- Stefan
>
> PS: Of course, the primary question for any new technology always is: Can it
> do porn? =) (I'll leave the answer to the readers, for now. =)
>

What are the advantages? More importantly, what are the use-cases?

To me the issue with writing applications that run across multiple
machines is reliable concurrent access to shared data, not maintaining
a consistent internal program state.

So I guess the answer to your question is no and probably I'd need a
compelling application that was considerably improved by using this
paradigm.

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

David Given
On 15/11/11 00:29, Josh Simmons wrote:
[...]
> What are the advantages? More importantly, what are the use-cases?

Hmm... how about a mail client? It's talking to a back-end server via
IMAP, which is an interface that's effectively stateless (as the
connection can be broken and recreated on demand). It stores a bunch of
local state, including cached messages, user preferences, pending
messages, and all the UI state.

I'm running it on an Android device reading my mail on the bus. I start
replying to an interesting message on Lua-L. My stop arrives. I chuck
the device in the bag and go home. Once I get home, I get my device out,
point it at my PC, and the mail client moves over to the desktop. I'm
still looking at the Lua-L folder, the compose window is open with my
text in it, and the cursor is exactly where I left it.

Given the MVC triad, the M part lives on the cloud and the VC part is
mobile.

[...]
> To me the issue with writing applications that run across multiple
> machines is reliable concurrent access to shared data, not maintaining
> a consistent internal program state.

That's actually pretty easy. Most cloud RPC protocols these days are
stateless, or nearly so, because it makes a huge number of problems go
away. Traditional AJAX involves setting up and tearing down a TCP/IP
session for every RPC request...

I think the biggest problem, though, is that data fundamentally cannot
be moved, only copied. But we really, really don't want two copies of
your app running at once. The move process needs to be destructive; once
the app has successfully transferred itself to another device the
version on the original device must not be allowed to run. Otherwise we
end up forking the state of the app, which means that both clones can
mutate independently, and *then* we end up with hideous issues trying to
merge them back together.

Stefan, what's the architecture? What APIs are available to such an app?
I assume they're in tough sandboxes with very restricted access to the
outside world.

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ "Never attribute to malice what can be adequately explained by
│ stupidity." --- Nick Diamos (Hanlon's Razor)


signature.asc (262 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Josh Simmons
On Tue, Nov 15, 2011 at 12:16 PM, David Given <[hidden email]> wrote:

> On 15/11/11 00:29, Josh Simmons wrote:
> [...]
>> What are the advantages? More importantly, what are the use-cases?
>
> Hmm... how about a mail client? It's talking to a back-end server via
> IMAP, which is an interface that's effectively stateless (as the
> connection can be broken and recreated on demand). It stores a bunch of
> local state, including cached messages, user preferences, pending
> messages, and all the UI state.
>
> I'm running it on an Android device reading my mail on the bus. I start
> replying to an interesting message on Lua-L. My stop arrives. I chuck
> the device in the bag and go home. Once I get home, I get my device out,
> point it at my PC, and the mail client moves over to the desktop. I'm
> still looking at the Lua-L folder, the compose window is open with my
> text in it, and the cursor is exactly where I left it.
>
> Given the MVC triad, the M part lives on the cloud and the VC part is
> mobile.
>

I don't know about you but my mail client on my desktop is
considerably different in nearly every way to my mail client on my
phone. What you're proposing already works anyway by sharing data
without moving the entire application. This also has the advantage
that you're not tied to a particular vendor, open standards and all.
This also seems to require only a single running instance at any one
time, which is unrealistic if for example something prevents you from
moving the app.

> [...]
>> To me the issue with writing applications that run across multiple
>> machines is reliable concurrent access to shared data, not maintaining
>> a consistent internal program state.
>
> That's actually pretty easy. Most cloud RPC protocols these days are
> stateless, or nearly so, because it makes a huge number of problems go
> away. Traditional AJAX involves setting up and tearing down a TCP/IP
> session for every RPC request...
>

I wouldn't say easy, but that's my point if you have a stateless data
sharing system already what do you gain by getting clever and sharing
the application state too?

> I think the biggest problem, though, is that data fundamentally cannot
> be moved, only copied. But we really, really don't want two copies of
> your app running at once.

I disagree with this, we can see the success of inherently distributed
architectures in version control when we look at git, mercurial and
friends. Multiple copes are something that's going to happen anyway
given the non-perfect world in which these apps have to exist.

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Jimmie Houchin
In reply to this post by Stefan Reich
On 11/14/2011 6:05 PM, Stefan Reich wrote:
Hi earthlings =)

OK, so I want to get very serious with this Mobile Lua idea now.

The execution core works. Hyperjumps work. Admin interface is functional too. (All in the next release.)

So it is time for some heavy duty marketing.

Here's what I know:

I know that the Mobile Lua concept is both innovative and sound; I know that the applications are boundless; and I pretty darn sure know that it is going to catch on pretty quickly.

What I am now looking for is a way to convince people of the advantages of code mobility.

Maybe you guys can help me out a little here.

For starters, I took a look at the list of the most popular programming languages and checked if they offer mobility. Here's the result (most popular languages listed first):

Language       Mobility
-------------------------
C              not mobile
Java           only in browser; not transitive
C++            not mobile
PHP            not mobile
JavaScript     only in browser; not transitive
Python         not mobile
C#             not mobile
Perl           not mobile
SQL            not mobile
Ruby           not mobile
Shell          not mobile
Visual Basic   only in browser (VBS); not transitive
Assembly       not mobile
ActionScript   only in browser; not transitive
Objective C    not mobile
Lisp           not mobile
Delphi         not mobile
Pascal         not mobile
Scheme         not mobile
Haskell        not mobile
Tcl            not mobile
Fortran        not mobile
Ada            not mobile

Lua            full transitive mobility (as Mobile Lua)

"Mobility", here, is defined as the ability of any program to move to another computer at any time while preserving its full inner state (code+data+threads). (Outside connections, naturally, may have to be recreated after moving.)

"Transitive mobility", then, is defined as the ability to move between computers more than once per script invocation.

(Note: There may be mobile agent frameworks for multiple languages listed above; but if they exist, they don't seem to be in widespread use. So it seems they are either too complicated, too heavy-weight or not practically usable for other reasons. I am very open for counterexamples if there are any!)

So it seems that Lua, with the advent of Mobile Lua, is now the only popular language offering full code mobility.

Question is: Are people aware of the advantages of code mobility? Are you aware? If not, what would it need for you to understand these advantages?

I have different ideas on how to demonstrate the possibilities of a mobile Lua - but I thought I'd check with you guys first to see if you have anything to say on this. I really hope that this list will prove a positive place and not one of "I want to criticize so I can bring you down".

-- Stefan

PS: Of course, the primary question for any new technology always is: Can it do porn? =) (I'll leave the answer to the readers, for now. =)

I don't know if this qualifies for what your trying to do or not but, you don't mention Smalltalk. :)

Smalltalk is different from all of the languages mentioned. All code is loaded into a running system. Code is updated, edited, modified live.

One interesting project for Pharo Smalltalk is Fuel. Fuel is an object serializer. It can serialize running code that has opened a debugger window. Open the serialized code in a new image and continue debugging the running code.

http://www.pharo-project.org/
http://rmod.lille.inria.fr/web/pier/software/Fuel

I don't know if either Smalltalk or Fuel are doing what you are looking at doing. But take a look and see what they are doing and may find some body going the same direction or may some interesting ideas.

Jimmie
Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

steve donovan
On Tue, Nov 15, 2011 at 4:33 AM, Jimmie Houchin <[hidden email]> wrote:
> Smalltalk is different from all of the languages mentioned. All code is
> loaded into a running system. Code is updated, edited, modified live.

I've always admired this model, it's like operating on a live patient.
It's true that Lua compilation happens instantly in most cases, but
there's often a lot of tear-down and tear-up going on with stopping
and launching a big server process.

It would be so cool to have a Lua development system which supported this model.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Jimmie Houchin
On 11/15/2011 12:08 AM, steve donovan wrote:

> On Tue, Nov 15, 2011 at 4:33 AM, Jimmie Houchin<[hidden email]>  wrote:
>> Smalltalk is different from all of the languages mentioned. All code is
>> loaded into a running system. Code is updated, edited, modified live.
> I've always admired this model, it's like operating on a live patient.
> It's true that Lua compilation happens instantly in most cases, but
> there's often a lot of tear-down and tear-up going on with stopping
> and launching a big server process.
>
> It would be so cool to have a Lua development system which supported this model.
>
> steve d.

I would so love that. It is the one thing that makes not using Smalltalk
so difficult if you like that model.

Smalltalk 80 was 31 years ago. It would be nice if computing would catch
up with some of the features it has. I hate restarting apps, OSes do to
a code update. It is frustrating that our systems are still so fragile.

The other nice thing about that model, is that with live objects, your
code knows so much more about itself than anything static analysis on
plain text can ever achieve. Fixing bugs in a live system is so much
nicer than doing a post mortem based upon an exit error statement of an
app or function which encountered an error or bug. In Smalltalk you can
often fix the bug and continue running. That is what its model is
designed to do. Smalltalk is not only like operating on a live patient,
but one who talks to you and can intelligently describe the problem,
where its located and lets you do what needs to be done.

But alas Smalltalk isn't perfect. It sometimes has a problem playing
well with others. It likes to own the world. When playing well with
others is required, Smalltalk may not be an option. Lua rocks here.

Lua with a live system and rich environment would be awesome. Bridge the
gap between the image based world and the file based one. But always
with Lua having a small kernel and embeddability as a foundation.

Jimmie

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

steve donovan
On Tue, Nov 15, 2011 at 8:29 AM, Jimmie Houchin <[hidden email]> wrote:
> continue running. That is what its model is designed to do. Smalltalk is not
> only like operating on a live patient, but one who talks to you and can
> intelligently describe the problem, where its located and lets you do what
> needs to be done.

Apparently some delicate brain operations are done with the patient
fully conscious (the brain itself has no pain receptors) so that they
can have continuous neurological status updates.

I experimented with incremental Lua compilation, and did a
proof-of-concept based on a suggestion by Peter Cawley; if you
recompile a function, you have to give it a fake lexical environment
for its upvalues and then patch them. Entertainingly bizarre stuff.

Having the object model completely available is the killer feature,
absolutely. Static analysis can get you surprisingly far (look at
David M's LuaInspect) but when your IDE can also directly ask the
patient, you're sitting pretty.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Dirk Laurie-2
In reply to this post by Jimmie Houchin
2011/11/15 Jimmie Houchin <[hidden email]>:

>>> Smalltalk is different from all of the languages mentioned. All code is
>>> loaded into a running system. Code is updated, edited, modified live.

> Lua with a live system and rich environment would be awesome. Bridge the gap
> between the image based world and the file based one. But always with Lua
> having a small kernel and embeddability as a foundation.

If you mean that your Lua program looks something like this:

   while true do
        perform()
        end

and you want some interrupt handler to change 'perform()' to 'play()'
while it is running, you're asking for a major change.

But what can you do that way that you could not also achieve by
assigning another function to the global variable called 'perform'?

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Vijay Aswadhati
In reply to this post by Stefan Reich
On 11/14/2011 4:05 PM, Stefan Reich wrote:

> Hi earthlings =)
>
> ...snip...
>
> "Mobility", here, is defined as the ability of any program to move to
> another computer at any time while preserving its full inner state
> (code+data+threads). (Outside connections, naturally, may have to be
> recreated after moving.)
>
> "Transitive mobility", then, is defined as the ability to move between
> computers more than once per script invocation.
>
> ... snip some more ...
>
> Question is: Are people aware of the advantages of code mobility? Are
> you aware? If not, what would it need for you to understand these
> advantages?
>
It is an interesting idea and power to you. At the risk of sounding like
an old fart I have to say this was something I fantasized about circa
1992 after reading "Metamagical Themas" [1]  - especially after reading
the Lisp essays; the author illustrates several examples of code writing
code, code mating with another piece of code to produce new code.

In my fictional framework, there would be these safe harbors with ports
open for active agents (as I called the mobile code) to travel across
the Internet seeking information - or in search of an answer to a
question. Like how today we send these space probes seeking answers.

It was fun for a while to chew on the idea but then had to get back to
reality. Like then I still don't have a good set of practical uses cases
on why I would want to set up these safe harbors to allow these active
agents to call on my ports and do something  - at least not in today's
view of the world.  It still remains too futuristic in my mind. But
don't let me or that  stop you...

Cheers,

[1]
http://www.amazon.com/Metamagical-Themas-Questing-Essence-Pattern/dp/0465045669 


Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Pierre Chapuis
In reply to this post by Stefan Reich
On 15.11.2011 01:05, Stefan Reich wrote:

> "Mobility", here, is defined as the ability of any program to move to
> another computer at any time while preserving its full inner state
> (code+data+threads). (Outside connections, naturally, may have to be
> recreated after moving.)

You might be interested in systems that do this at the OS level too.
For instance Kerrighed: see http://kerrighed.org/man/migrate.1.html
and http://kerrighed.org/man/checkpoint.1.html.

Obviously another way to do such a thing is to migrate the whole
virtual machine with something like Xen.

> So it seems that Lua, with the advent of Mobile Lua, is now the only
> popular language offering full code mobility.

As said by other people I feel like you forget Smalltalk.

> Question is: Are people aware of the advantages of code mobility? Are
> you aware? If not, what would it need for you to understand these
> advantages?

I do understand the advantages of such mobility, especially in the
context of high availability and large scale distributed applications.

Another use case (I don't think I've seen something like that yet)
would be: I'm running a program on my desktop computer, I have to go
somewhere, I migrate it to my laptop and just take my computation
with me.

I don't think mobility is very useful without the ability to snapshot
a process (ie. pause and persist to disk) though, and once you have
that mobility is rather easy to obtain.

It's not exactly the same thing but you might also be interested in
the concept of "reincarnation" of Minix3:
http://www.linuxpromagazine.com/Online/News/Video-Andrew-Tanenbaum-on-Bugs-and-Minix-Reincarnation-Server

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Valerio
In reply to this post by Stefan Reich
Hello Stefan,

On Tue, Nov 15, 2011 at 1:05 AM, Stefan Reich <[hidden email]> wrote:

OK, so I want to get very serious with this Mobile Lua idea now.

What I am now looking for is a way to convince people of the advantages of code mobility.

Is the code available somewhere?
 
I have different ideas on how to demonstrate the possibilities of a mobile Lua

Me too ;-)
 
- but I thought I'd check with you guys first to see if you have anything to say on this. I really hope that this list will prove a positive place and not one of "I want to criticize so I can bring you down".

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Louis-Philippe
You should probably also look at erlang.
Code is always live, updated while running, and execution can be spread accross a whole network of machines.

2011/11/15 Valerio Schiavoni <[hidden email]>
Hello Stefan,

On Tue, Nov 15, 2011 at 1:05 AM, Stefan Reich <[hidden email]> wrote:

OK, so I want to get very serious with this Mobile Lua idea now.

What I am now looking for is a way to convince people of the advantages of code mobility.

Is the code available somewhere?
 
I have different ideas on how to demonstrate the possibilities of a mobile Lua

Me too ;-)
 
- but I thought I'd check with you guys first to see if you have anything to say on this. I really hope that this list will prove a positive place and not one of "I want to criticize so I can bring you down".


Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Jay Carlson
In reply to this post by Stefan Reich
On Mon, Nov 14, 2011 at 7:05 PM, Stefan Reich
<[hidden email]> wrote:

> "Mobility", here, is defined as the ability of any program to move to
> another computer at any time while preserving its full inner state
> (code+data+threads). (Outside connections, naturally, may have to be
> recreated after moving.)

You may be interested in Obliq. http://lucacardelli.name/Obliq.html
(start with the slides)

Obliq allows closures to pass over the network, but it preserves
lexical scoping. In Lua terms:

local myio = io
function root()
  local fn = myio.open("/etc/passwd")
  return fn:read()
end
print(computeServer.run(root))

In this case, the value of myio is copied as an upvalue of root.
However, to preserve meaning, myio continues to refer to io on the
sending machine; it's replaced with a proxy if necessary. So the same
result will be printed whether computeServer is part of the same
process, a different local process, or a remote process: it prints the
first line of /etc/passwd on your machine.

computeServer may expose local objects as an argument to root.

You may want to borrow liberally from E ( http://erights.org/ ) as well.

Jay

(Obliq predates JavaScript by about a year; March of 1994.
news:2mjegu$[hidden email]
http://groups.google.com/group/comp.lang.modula3/msg/58fa5c4067c4690d
)

Reply | Threaded
Open this post in threaded view
|

Re: Mobile Lua - coming on strong

Jay Carlson
I'll feel guilty if I let that go without context.

On Tue, Nov 15, 2011 at 11:16 AM, Jay Carlson <[hidden email]> wrote:

> Obliq allows closures to pass over the network,

...which leads to disaster, if not used very carefully and precisely.
Remote procedure call is a bottomless swamp of bugs, especially when
interfaces are not designed specifically for the purpose. E is a
rebuttal of Obliq in some ways.

If you're doing any kind of network/distributed computing, the famous
must-read paper is "A Note On Distributed Computing",
http://labs.oracle.com/techrep/1994/abstract-29.html [1] but in the
process of searching for it I found [2] "A Critique of the Remote
Procedure Call Paradigm" by Andrew S. Tanenbaum and Robbert van
Renesse ( http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf ) from
years earlier.

Jay

[1]: Sun TR-94-29, Ann Wollrath, Geoff Wyant, Jim Waldo and Samuel C.
Kendall, November 1994. It is amazing how fast Oracle erased Sun's
name; it seemed like ritualized submission. Only one step from Sun to
Oracle; Modula-3 went Olivetti/DEC SRC->Compaq->HP.
[2]: Found at http://news.ycombinator.com/item?id=199181 .