Oracle lowers the flag on Fortress language project(theregister.co.uk)
theregister.co.uk
Oracle lowers the flag on Fortress language project
http://www.theregister.co.uk/2012/07/23/oracle_fortress_project_halted/
6 comments
Interesting that the challenge they felt particularly worth calling out wasn't about solving hard algorithms or design problems, but rather making those solutions function on the limited JVM platform. Perhaps this will give pause to the next language developer tempted to target the JVM for no reason other than its popularity.
Interesting that the challenge they felt particularly worth calling out wasn't about solving hard algorithms or design problems, but rather making those solutions function on the limited JVM platform. Perhaps this will give pause to the next language developer tempted to target the JVM for no reason other than its popularity.
From Guy Steele's blog post[1]:
"Nevertheless, over the last few years, as we have focused on implementing a compiler targeted to the Java Virtual Machine, we encountered some severe technical challenges having to do with the mismatch between the (rather ambitious) Fortress type system and a virtual machine not designed to support it (that would be every currently available VM, not just JVM)."
So it doesn't sound like this is any particular indictment of the JVM.
[1]: https://blogs.oracle.com/projectfortress/entry/fortress_wrap...
From Guy Steele's blog post[1]:
"Nevertheless, over the last few years, as we have focused on implementing a compiler targeted to the Java Virtual Machine, we encountered some severe technical challenges having to do with the mismatch between the (rather ambitious) Fortress type system and a virtual machine not designed to support it (that would be every currently available VM, not just JVM)."
So it doesn't sound like this is any particular indictment of the JVM.
[1]: https://blogs.oracle.com/projectfortress/entry/fortress_wrap...
They published a paper on it last year, "Type-checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance": http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf (LtU discussion: http://lambda-the-ultimate.org/node/4236)
If you're doing an "ambitious" type system, you might as well do your own VM. Trying to shoehorn stuff into jvm/clr/parrot/whatever is hardly ideal.
An indictment of VMs in general, then. They're almost universally targeted at supporting a particular language, and cause problems when more advanced concepts (such as cutting-edge type systems) must be implemented.
With InvokeDynamic the JVM is pretty much the first to open up its full set of compiler optimizations to any language that implements its method dispatch semantics using InDy's set of tools. InDy allows language implementers to define their own method dispatch semantics, polymorphic inline caches, and deoptimization in the event that assumptions change e.g. the class hierarchy has been modified.
There is rather more to type systems than method dispatch.
Type checking at method dispatch is the only part of the equation (literally, in the case of Fortress) where the JVM would come into play. Everything else happens ahead of time in the compiler.
With InDy, the JVM can do a one-time check, verifying whatever security invariants the language has put in place, and after that, the MethodHandle is in InDy's polymorphic inline cache and the security checks can be skipped on subsequent calls. All subsequent calls dispatch at Java speed and can be inlined by HotSpot just like any other Java method.
Writing your compiler on top of the JVM using InDy might help make this clearer!
With InDy, the JVM can do a one-time check, verifying whatever security invariants the language has put in place, and after that, the MethodHandle is in InDy's polymorphic inline cache and the security checks can be skipped on subsequent calls. All subsequent calls dispatch at Java speed and can be inlined by HotSpot just like any other Java method.
Writing your compiler on top of the JVM using InDy might help make this clearer!
> that would be every currently available VM, not just JVM
Perhaps of just the current VM's, and not some intrinsic limitation of VM's in general.
Perhaps of just the current VM's, and not some intrinsic limitation of VM's in general.
I do wonder what about the JVM makes it harder as opposed to using any other platform? Would it have been easier on Javascript or Ruby?
It's not about the language their implementation is written in (although many people find MLs and Lisps to make compilers and interpreters much easier to implement), it's about the machine that their implementation targets. The JVM imposes many restrictions on and makes many assumptions about the behavior of client languages as a direct result from being built to host Java. I have no doubt that the CLR is similar. Javascript and Ruby are not typically compilation targets, bar things like ClojureScript.
I'm curious if the impedance mismatch Guy Steele describes between Fortress's type system and the JVM could be remedied by InvokeDynamic. Unfortunately he didn't mention anything about it in his blog post.
Bummer, I was really interested in Fortress. There really seemed to be some interesting stuff going on there. Ah well, maybe some of the research will help with Java or something else down the road.
Or, perhaps some plucky startup will pick up the technology and next week we'll see a headline "Startup raises $4M to develop Fortress" or something of that ilk.
Or, perhaps some plucky startup will pick up the technology and next week we'll see a headline "Startup raises $4M to develop Fortress" or something of that ilk.
VCs are interested in spending millions on programming language R&D? Where do I sign up?
Well, Greylock invested[1][2] in Typesafe, the company backing Scala.
[1]: http://greylockvc.com/2011/05/12/why-we-invested-in-typesafe...
[2]: http://actu.epfl.ch/news/epfl-professor-launches-typesafe-wi...
[1]: http://greylockvc.com/2011/05/12/why-we-invested-in-typesafe...
[2]: http://actu.epfl.ch/news/epfl-professor-launches-typesafe-wi...
Interesting! Not only did they invest in them, they did so explicitly because of Scala. Still, I suspect they'd have had a much harder pitch without Java compatibility; a quick review of their materials seems to suggest that bringing existing technology to a Java environment, rather than developing new technology, is Typesafe's business.
> "Startup raises $4M to develop Fortress"
Nope.
Nope.
Too bad for Quora: https://twitter.com/benjamn/status/74191660543778816
> Ben Newman @benjamn
> @yaaang Your sources are stale. We evaluated Scala, yes,
> but we are now 90% committed to Fortress, a modern dialect
> of FORTRAN.
> Ben Newman @benjamn
> @yaaang Your sources are stale. We evaluated Scala, yes,
> but we are now 90% committed to Fortress, a modern dialect
> of FORTRAN.
Why? Fortress is open source (BSD-licensed). It'll continue to be available forever and as long as anyone is using it and interested it'll keep getting fixes and features.
[deleted]
AFAIK, Guy Steele is in this project. What'll happen to him?
If you click on through you can see Guy's blog post that this article is based on: https://blogs.oracle.com/projectfortress/entry/fortress_wrap...
He seems to imply that he'll be moving on to some other project at Oracle, but it's not really stated explicitly.
He seems to imply that he'll be moving on to some other project at Oracle, but it's not really stated explicitly.
Presumably, he'll continue to head the Oracle Labs Programming Language Research Group (which most likely is doing more than just researching Fortress).
Although maybe the decision will be related to him going somewhere else (I'd imagine there's a lot of places that would fall all over themselves to hire Steele).
Although maybe the decision will be related to him going somewhere else (I'd imagine there's a lot of places that would fall all over themselves to hire Steele).
I hope he moves on to a better company. :) The guy is legend. It's hard to find much good to say about Oracle these days.