A new Java-ish programming language: Meso

[Stefan]

Syntax-wise, Meso looks almost identical to Java, except some differences in the package and import statements.  But if you understand how Meso's import statement works, you will realize that Meso is actually very different from Java.

I created this language to demonstrate a new network programming paradigm in which programs link to each other in a similar way as web pages link to each other.  I applied this idea to the Java language and created Meso, but the same idea can be applied on many other languages.

The source code of Meso is published on github under the GPL v3, and I am currently working on an IDE for it.  If you are looking for a fun project to work on during the holidays, why not give it a try :)

Here is the project website: http://gpgrid.org

Stefan

[Mark Derricutt]

Interesting - I'd love to take a look but your server seems down.

Any reason for choosing GPL v3 at all?  I was wondering, do you have a runtime library and if so - is that also under GPLv3?  ( i.e. meaning no commercial applications can be built using Meso )?

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

Stefan

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/fidKeC2AsFoJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Roland Tepp]

An IDE from scratch, or an extension to NB/Eclipse/IDEA?

In case of Eclipse, I would urge you to take a deep look at XText...

[Stefan Hong]

The server is up, but you might need to wait a little longer to load the page since it is a busy server at my school. I will probably move the site to amazon someday...

The language is still in the proof-of-concept stage and does not have any library yet. If it does, I will either use the GPL with linking exception or LGPL for the library.

Stefan

[Stefan Hong]

I am planning to write an Eclipse plugin, and I am indeed interested in Xtext. But it seems to me that I have to use the Xtext grammar for the language, which pretty much means that I have to rewrite the whole thing.

Not sure with one is easier though, rewrite the language, or write the IDE plugin from scratch :P

Stefan

[Ricky Clarkson]

Without wishing to get into a holy war I'd like to suggest that if you're unsure about licences it's best to go with BSD. That gives your users some confidence that their time wasted learning and writing code for your language won't be wasted when they change jobs.

Or worse, should *you* change jobs you might find yourself unable to use the language you created just because you don't own all the copyright. Best to stay out of that toenail-fest.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

[Reinier Zwitserloot]

Let's say I don't need any runtime web interaction, i.e. I'm not building a twitter client but I just want, say, google Guava to use in my app, so I do something like:

import imop:code.google.com/guava/guava.ImmutableList;

does this mean that the compiler will make a call to the web to resolve this? Will it do so every time, or does it create some sort of cache? What about runtime? Will it still need a web connection to run this app or will it run without making any net requests?

What about versioning of guava.ImmutableList?

[Ricky Clarkson]

I'd be more worried about how you make sure you're not calling out to
something that will expose your private data. I'd want some form of
data tainting a la Perl that prevents AccountNumber from going over
the wire, for instance. And how do I know that the results are
correct from a call, do we need to send this over HTTPS so that we can
validate the certificate chain? The nits that need picking could make
or break this kind of approach.

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/javaposse/-/mFajcyn_eg8J.

[Stefan Hong]

If you just need to use a native Java library, you can import it like so and no network communications is needed:

import java:guava.ImmutableList;

If you do something like this instead:

import imop:code.google.com/guava.ImmutableList;

It means that the ImmutableList is actually hosted at google, and therefore no instances of that will be created in your computer. You can only use them remotely. Note that Meso does not download source code over the network. It only acquires an abstract definition of the imported resource for type checking.

[Stefan Hong]

I haven't focus on the security topics yet. But since IMOP is very similar to HTTP, I guess we can at least apply the same tricks we use in web apps to Meso programs, such as IMOP over SSL (IMOPS) and session cookies.

Having said that, I think not all applications are equally concerned about security. Public services such as maps, weather services, flight schedules... can all benefit from a cleaner way to represent their APIs where the security is a lesser concern.

[Pete F]

Leaving the absurd bike-shedding about licenses to the side for a
moment..

I don't really get the zen of GPG/IMOP/Meso.

You compare it to REST -yet it seems to be an RPC mechanism though
and through.

If I may be so bold (and I probably misunderstood) you seem to make
the classical error of so-called "low REST" viz. programming the web
via RPC, not resources.

I feels more like SOAP, but with "lazy" retrieval of types (rather
than up front in some wsdl etc) and json instead of xml -and meso
brings to mind F# type providers

Beyond that, what does it do (that SOAP doesn't)?

Does the client push code to the server? (eg PUT+ EVAL in place of PUT
+ GET)

Does one create remote persistent objects?

It seems odd to me to expose the protocol in a user friendly way (a la
REST over SOAP) and then bury it again in a compiler.

I await embarrassment at having missed the point :-)

Pete F

[Stefan Hong]

There are two primary differences between web services and the GPG paradigm: reflection and dynamic binding.

1. reflection

In web services, if I tell you that I have a port type named "IService" under the namespace "urn:foo.soap", there is no way you can know the port type's definition unless I give you its WSDL file.  There is no authoritative definition of the type either - anyone can create a new WSDL file to give a random definition to that port type.  Knowing a type's name alone is not enough to know what it is.

In contrast, if I tell you that I have an abstract interface named "imop:foo.com/IService", the name is associated with a globally unique definition - the one you can reflect from foo.com using IMOP.  Knowing the name alone is enough to know what it is, no matter where you are in the world.  I believe this is essential to facilitate interoperability in a large-scale open system.

2. dynamic binding

With the reflection capability, our programs can interact with unknown remote resources at runtime.  For example:

import imop:foo.com/IService;

...

   void func( IService obj ) {

      obj.foo();

   }

At runtime, I can pass any unknown remote reference, say "imop:bar.com/MyObject", to the method, and the runtime system will be able to use reflection to decide whether to accept it as an argument:

   // pseudo code

   ref = imop:bar.com/MyObject;

   if ( ref  instanceof  imop:foo.com/IService )

      assign_ref_to_obj();

   else

      throw_runtime_exception();

We use interface types this way everyday in our Java programs, but we are yet able to do the same thing in a distributed system.  It is not obvious to me that how we can do this with web services.

Hope this help :-)

Stefan

[Pete F]

>>
Hope this help :-) << it does, but i'm just not getting that dried
mud embarrassment feeling yet :-)

>>In contrast, if I tell you that I have an abstract interface named
"imop:foo.com/IService", the name is associated with a globally unique
definition<<

Is this global, rather than "types per service" angle the key then?

So from you example "imop:twitter.com/public.Timeline" -the big
winner wouldn't necessarily be twitter directly -but rather would-be-
twitter.com's ability to not only implement imop:twitter.com/
public.Timeline but to declare their implementation formally (rather
than just say "we implement a twitter like api, no really" somewhere
on their site)

Does it follow that you *must* then do the dynamic binding, rather
than the latter being a good thing of itself?

In your example

>>
// pseudo code
ref = imop:bar.com/MyObject;
if ( ref instanceof imop:foo.com/IService )
assign_ref_to_obj();
else
throw_runtime_exception();
<<

does

instanceof imop:foo.com/IService

imply a round trip to the remote node (!!) -or are you already
sitting on a cache of type information (as you would be having
consumed some wsdl)

I *thought* that this was what Reinier Zwitserloot's was asking above,
but that question may have been about caching code (which is certainly
how you answered it)

Can't say I would want to pitch this stuff to Gilad Bracha ;-)

Pete F

[Stefan Hong]

On Monday, December 5, 2011 4:13:49 PM UTC-8, Pete F wrote:

Is this global, rather than "types per service" angle the key then?

Yes.

Java types are defined in a global scope, but that global scope is not really "global" in the geographical sense.  It is a confined runtime environment established by classloaders.  A Java class named "foo.Bar" can have different definitions on different machines.

I try to expand that scope to the true global scope that covers the whole world.  Under such scope, we can use the same Java syntax to write programs, but every data type we define and reference to has a unique place in the world.  Two machines can 'see' the same definition of a type named "imop:example.com/foo.Bar", and only example.com can provide its definition.  In other words, the true global scope is established by everyone on the Internet, not your local configurations.

 

Does it follow that you *must* then do the dynamic binding, rather

than the latter being a good thing of itself?

Dynamic binding is only necessary when an unknown object is encountered at runtime.  For singleton objects whose type is known at compile time, it is indeed not necessary.

My current implementation bound both cases dynamically, but it is just a proof-of-concept version anyway ;-) I am working on rewriting the whole thing using Xtext and generate pure Java classes from Meso source code.  Dynamic binding will only be used when necessary.

 

does

 instanceof  imop:foo.com/IService

 imply a round trip to the remote node (!!)  -or are you already
sitting on a cache of type information (as you would be having
consumed some wsdl)

Wsdl is like a description of a singleton object, so we can statically bind to any service described by wsdl.  But if we want our client program bind to an abstract service interface, a round trip to the remote node at runtime would be necessary since you haven't seen the concrete service at compile time.  If we put the returned service descriptor in a persistent cache with an indefinite TTL, than the actual round trip traffic is only needed once.

 

Can't say I would want to pitch this stuff to Gilad Bracha ;-)

Well, I don't personally know him, but I would definitely love to have a chance to chat with him :-)

Stefan