Lex Spoon discusses the Scala programming language including the origin of Scala, the philosophy behind Scala, the Scala feature set, Object-Oriented and Functional programming in Scala, examples of Scala code, writing DSLs, how Scala is converted into Java, Scala performance, Abstract Data Types, unapply, actors and partial functions. Lex Spoon divides his time between two posts: he works at EPFL in Switzerland on the Scala team, and at IBM Research in New York on X10.
Fan is an OO, functional programming language designed to cross compile to both the Java and .NET platforms. It provides a concise syntax along with elegant, cross portable libraries.
Nailgun is a client, protocol, and server for running Java programs from the command line without incurring the JVM startup overhead. Programs run in the server (which is implemented in Java), and are triggered by the client (written in C), which handles all I/O.
Jaskell is a functional scripting programming language that runs in JVM. The name "Jaskell" stands for Java-Haskell, but it is not haskell 1. Most of the current scripting languages are Object-Oriented. Though they more or less have functional tastes (Ruby's sexy closure, for example), the heart of them are still Object-Oriented. One of the most important essenses of functional programming (combinators) is yet to be brought into Java. 2. Jaskell brings with it higher order function, function currying, pattern match and monadic combinator support. 3. Monadic combinator is ideal for designing Domain Specific Language. It is relatively easy to tailor Jaskell runtime to make domain specific syntax look like simple atomic statements. See Neptune for a real example. 4. Jaskell is nothing but a Java library that passes Java objects in and out of the interpreter.
Efficiently translating Haskell to JVM Bytecode using GHC's intermediate language, STG. LambdaVM is the proof that complete and efficient translation is possible. LambdaVM is a set of patches to GHC's which extend it to fully support generating useable JVM bytecode. It modifies the three primary components of GHC: * The compiler itself: The compiler has been modified to transform STG, one of GHC's many intermediate languages, to JVM bytecode. * The runtime system (RTS): GHC's RTS implemented as a mix of C and C-- has been reimplemented in Java. * The base libraries: GHC's base libraries have been modified to run on top of Java's standard libraries rather than ANSI C/POSIX libraries. October, 2008 Update LambdaVM is coming back! I've fixed all the GHC 6.8.x build problems and the instructions below should once again work. LambdaVM itself is still based on a circa November, 2007 GHC HEAD but moving all my changes to the current HEAD is next
NestedVM translated C (actually any language supported by GCC) programs to JVM bytecode. You can find some more information at http://nestedvm.ibex.org. How it works * Paper * Talk How to use it * Quick Start Guide * David Aubin's Cygwin Building Guide * Building Tips * Unix Runtime (a.k.a. "What the heck does this error mean about unknown syscall") Similar Projects * Cibyl
LambdaVM is a JVM backend for GHC. It is available at http://darcs.brianweb.net/ghc. October, 2008 Update See http://www.cs.rit.edu/~bja8464/lambdavm/ Documentation * Building Guide * FFI * Exceptions * Concurrency Misc Notes * Implementation * Todo * NestedVM Integration
mainly marketing articlle by cofiiunder What if you didn't have to do any of this funny business to get scalability and reliability? What if the JVM had access to a service that you could plug into to make its heap durable, arbitrarily large, and shared with every other JVM in your application tier? Enter Terracotta, network-attached, durable virtual heap for the JVM. In the spirit of full-disclosure, I'm a co-founder of Terracotta and work there as a software developer. Terracotta is an infrastructure service that is deployed as a stand-alone server plus a library that plugs into your existing JVMs and transparently clusters your JVM's heap. Terracotta makes some of your JVM heap shared via a network connection to the Terracotta server so that a bunch of JVMs can all access the shared heap as if it were local heap. You can think of it like a network-attached filesystem, but for your object data; see Figure 1.