Thursday, August 30, 2012

If you do science fiction, please do it right

I'm watching Outland,  a 1981 film directed by Peter Hyams and starring Sean Connery.

In one of the first scenes (the second, actually) you see Jupiter as seen from Io. It occupies most of Io sky. So, I asked myself if it really looks like that.




Simple trigonometry yields the angle under which  Jupiter is seen:

r = radio of Io
R = radio of Jupiter
d = distance of the center of Io from the center of Jupiter

angle = 2 * arcsin (R / (d - r))

Looking up the data on the Wikipedia the result is

r = 1821 Km
R = 71492 Km
d = 41700 Km

angle = 19 degrees.

Note. If you don't feel at ease measuring size with angles, well, consider that Hellenistic Greeks already did it in the 3rd century B.C.. The approach was long misunderstood later, to be rediscovered and re-understood during the Scientific Revolution. The idea is that the angle is the apparent size: if you also know the distance than you'll know the real size too.

Which is a little less the one fourth of the angle (90 degrees) from the horizon to the point in the sky above you head.

So I think the movie is wrong. And, if you do science fiction, please do it right.

PS. This is how Jupiter should be seen from Io. Supposing you're watching the screen from 50 cm far, doing trigonometry the other way round, yields about 17.5 cm for the apparent diameter of Jupiter (I assembled three images using GIMP and did a perspective transformation of an Io image).






























PSS. I asked Celestia, an open source 3D astronomical object visualization software. Here is the result. I was wondering if Europa and Ganymede, other two nearby Jovian satellites, could contribute to an even more appealing picture, but Celestia showed me that they actually appear as tiny spots from Io.





Tuesday, August 14, 2012

Andy

This is Andy, I drew it as a new wallpaper for my own Android phone.


Saturday, August 11, 2012

Java Language in 2015

Consider these APIs, frameworks and patterns:

1) JNDI (Java Naming and Directory)
2) JMX  (Java Management Extension)
3) JPA (Java Persistence Framework)
4) Spring
5) DI (Dependency Injection) and Inversion of Control (IoC)

They all deal with objects (don't laugh...), with instances, as opposed to dealing with the classes these instances originate from.

Yes, it's curious that Object Oriented languages care so much natively about classes, but are very mean instead as instances are concerned, and in fact so many frameworks have been born to address this problem, since the language itself offers little support. Object Oriented language should be renamed Class Oriented language, I would reserve the the former denomination for a language that doesn't exist yet.

1) JNDI gives instances a name, a global name, so that they aren't anonimous instances anymore. While some objects are temporary, they live as long as a method executes, some other may live as long as the JVM lives. Besides, if you want them to become acquainted with one another, they should have a name.
 
2) JMX is about allowing knowledge and modification of the state of some well known objects from outside the JVM. Oddly, JMX has its own naming scheme and registry, and that's absurd: we would like to have just one mechanism to name instances.

3) Spring. It started as just a framework to initialize some instances from a configuration stored in a file and wire these instances together. It implements the DI and IoC patterns.

So, on the one hand there is some proximity with JMX, since, while the former (JMX) allows to modify the state of instances at runtime, the latter (Spring) allows to setup the initial configuration when instances are created. 

On the other hand, there is some proximity with JPA, since also JPA is able to reinitialize some instances from a stored state.

Also, Spring sports its own naming scheme and registry.

4) JPA allows to save and restore the state of some objects from a database.

5) IoC is when an instance is not created directly by the application code. The method signature 'public static void main (String []) argv' is the primordial IoC framework.  DI is when a reference to an instance is not acquired directly by writing in a program a reference assignment.


Bringing in it all together

What if.

We had just one mechanism (JNDI made simple?) to assign some well known object a name. But maybe not only a name, but also, why not, humans may enjoy a description and an icon.

We had just one mechanism (JPA?) to restore the state of instances from a known state, previously saved.

We had the possibility to modify from outside the JVM the state of known instances (JMX totally rewritten in POJO terms?)? This state could then be saved to the persistence store and it would again be there on a new bootstrap.

We could annotate a missing dependency (from an instance, not from a class!) and resolve it at runtime through a named well known object? Of course this is what Java Enterprise always had but with tons of unnecessary machinery. This shouldn't be Enterprise programming.

All this shoudn't be achievable through frameworks often not working very well with one another, it should be there at the heart of an Object Oriented platform.

PS: I've taken a look at DI and CDI. DI is fine for me. It should lie at the heart of the Java Platform. I'm more suspectful towards CDI. For example scope management smells like a workaround for bad programming practices. Event dispatching is more insteresting.








Things I would like to have in the Java Programming Language

1) The class name is the class object

If Foo is a class than Foo should be the class object, not Foo.class

2) Method literals

If class Foo has a method bar than  

Foo.bar

should be an instance of the java.lang.ref.Method class, i shoudn't have to write

Foo.class.getMethod ("bar", null)
 
3) Method literals (part II)

If object foo of class Foo has a method bar, than foo.bar should result in an instance of a new class java.lang.ref.InstanceMethod which holds a reference to the bar object and to the Foo.bar method.

4) Method literals (part III)

If foo is an instance of the  java.lang.ref.Method, than foo () should result in method invocation, I should not have to use foo.invoke ().The same applies if foo is an instance of the new class java.lang.ref.InstanceMethod

5) Operator overloading on java.lang.Number instances.