Top five languages
Charles Oliver Nutter
JVM language projects. This can certainly include languages that aren't
under active development right now or that don't have a large following.
I just want to gather a list of languages that "we implementers" and JVM
language enthusiasts think the world should know about (and which are
good examples of the work we're doing on VM).
These do not represent languages you think are the "best" or "most
important" or anything like that, so be honest. It's just going to be
added to a flat list, probably in alphabetical order.
Here's my top five "interesting" language projects:
JRuby - pushing the bounds of class generation and dynamic invocation
perf, as well as pulling a whole other platform into the JVM ecosystem
Groovy - providing almost all Java language features and two-way
integration in addition to many (most?) dynamic language features found
in languages like Ruby.
Jython - A second opportunity to pull a whole platform into the JVM
world, and a very receptive Python community that doesn't hate anything
with a J in it
Scala - Not obvious? Solid integration with Java and object/functional
goodness.
Duby - Ok, I'm biased, but if I ever get time to work on it Duby could
marry Ruby syntax with a full complement of Java features and local type
inference. Exactly what I've been looking for.
- Charlie
Charles Oliver Nutter
> These do not represent languages you think are the "best" or "most
> important" or anything like that, so be honest. It's just going to be
> added to a flat list, probably in alphabetical order.
I realized my topic ende dup as "Top five languages" when I in know way
meant this to be a "top" anything. Just toss out five languages you
happen to be following, or that you hope to follow in the future.
- Charlie
Ola Bini
JRuby
Scala
Clojure
ioke
Duby.
You want justifications for those? =)
--
Ola Bini (http://ola-bini.blogspot.com)
JRuby Core Developer
Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
Practical JRuby on Rails (http://apress.com/book/view/9781590598818)
"Yields falsehood when quined" yields falsehood when quined.
Charles Oliver Nutter
> My top five:
>
> JRuby
> Scala
> Clojure
> ioke
> Duby.
>
> You want justifications for those? =)
No, but how about a description and status update for ioke I can use in
the talk :)
- Charlie
Richard Warburton
> JRuby - pushing the bounds of class generation and dynamic invocation
> perf, as well as pulling a whole other platform into the JVM ecosystem
>
> Groovy - providing almost all Java language features and two-way
> integration in addition to many (most?) dynamic language features found
> in languages like Ruby.
>
> Jython - A second opportunity to pull a whole platform into the JVM
> world, and a very receptive Python community that doesn't hate anything
> with a J in it
>
> Scala - Not obvious? Solid integration with Java and object/functional
> goodness.
>
> Duby - Ok, I'm biased, but if I ever get time to work on it Duby could
> marry Ruby syntax with a full complement of Java features and local type
> inference. Exactly what I've been looking for.
Just an observation - but if you are looking for listing a variety of
languages then I would be inclined to list things that are highly
distinct. For example, listing both Jython and JRuby seems somewhat
redundant. Obviously they are both distinct implementations, with
differing groups - but is there really that much novelty to the
implementation of one compared to the other? Perhaps just go with
JRuby.
I would replace it with a language/implementation that isn't
necessarily in a perfect situation to be implemented on top of the
JVM, but whose problems are the kind of things that the Da Vinci
project aims to solve. There's numerous things that have been
mentioned on this list over time, e.g. CPS style not integrating well
with normal java calling conventions (I'm thinking of maybe a Scheme
implementation), lack of tail call optimisations (please note this not
a thread to dig up that can of worms again) - so perhaps one of the
failed functional languages of the JVM projects (MLj?) or something of
that nature. Just something a little different instead of all the
'Usual Suspects'.
Good luck with your talk.
Richard
Ola Bini
come within the next few days. =)
Matt Fowles
It is not open source, but StreamSQL from StreamBase is a 'Complex
Event Processing' language that runs on the JVM.
So that gives you an idea of a very different type of language that
runs on the JVM.
Fair warning: I work for StreamBase.
Matt
Charles Oliver Nutter
> Just an observation - but if you are looking for listing a variety of
> languages then I would be inclined to list things that are highly
> distinct. For example, listing both Jython and JRuby seems somewhat
> redundant. Obviously they are both distinct implementations, with
> differing groups - but is there really that much novelty to the
> implementation of one compared to the other? Perhaps just go with
> JRuby.
Yes, you make a good point. Whatever list eventually comes out of it
I'll probably group them by what challenges they face, and try to draw
out the commonality between them as areas we're working together.
- Charlie
Jon Harrop
I'd appreciate any information at all on some of these. :-)
JRuby is a Ruby implementation. Scala is programming language research trying
to integrate FP and OOP. Clojure is a Lisp dialect on the JVM. I can't find
anything on ioke. I can only find a single blog post mentioning Duby.
I suppose my vote goes to:
. OCamlJava
. Scala
. CAL
...
I'm not particularly interested in any of those though (and I've run out). I
will be extremely interested if anyone starts something more like F#! :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
Daniel Green
Scala
JRuby
Groovy
Jhaskell (http://sourceforge.net/projects/jhaskell)
OCaml-Java (http://ocamljava.x9c.fr/)
And perhaps some implementation of Lisp or Scheme if a decent one
exists. I imagine there's an abundance of them.
But certainly not Java. Who uses that anymore? ;-)
Daniel Green
> world, and a very receptive Python community that doesn't hate anything
> with a J in it
>
on Rails. From a marketing stand point, this a great way to chose
languages, as long as we remember to take into account the likeliness
of adoption. Take perl for example, it has a higher market share than
Python, but a fantastic collection of easily accessible libraries and
a devoted albeit stubbern following... and being a member of that
community for quite some time, I remember allot of J hate going on...
If there is ever a JVM implementation of C#, let's not walk to it, but
run. And then turn around and run in the opposite direction as we
dodge the bombardment of Microsoft lawyers that will rain down on us.
Guillaume Laforge
--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com
Charles Oliver Nutter
> I'd appreciate any information at all on some of these. :-)
>
> JRuby is a Ruby implementation. Scala is programming language research trying
> to integrate FP and OOP. Clojure is a Lisp dialect on the JVM. I can't find
> anything on ioke. I can only find a single blog post mentioning Duby.
There should be at least two, both by me. I know I haven't given a
formal introduction yet, but it's little more than a hobby project at
the moment:
http://headius.blogspot.com/2008/03/duby-type-inferred-ruby-like-jvm.html
http://headius.blogspot.com/2008/03/more-fun-with-duby.html
The primary use case for Duby right now is "me", to use when I don't
want to use Java but don't want to lose performance. The primary feature
I see that makes this stand apart from others in the arena (Scala) is
that I explicitly want it to have no runtime dependencies. It's a new
Ruby-like syntax to produce JVM bytecode. The magic is all in the compiler.
Mark Haniford
Patrick Wright
Scala
Kawa
Pnuts
Talc -
F3 - such a good name :)
Re: Kawa, I'm specifically interested in the reusable language
infrastructure that underlies it, which seems like a big plus--oddly
enough, even used in one attempt for Perl on the JVM, see -
http://www.ebb.org/bkuhn/writings/technical/thesis/node40.html for
example. I think it's a good example of the sort of learn-and-share
approach by language designers and developers which in the long run is
as important, if not more important, than bragging right about how
many languages run on the JVM.
Cheers
Patrick
PS: CAL, Fan, Clojure, Nice
Daniel Green
were all introduced to the this group through the Scala community, or
we're in for some glorious objected oriented functional times. I'd
like to see a graph of the trends of these fledgling languages.
Perhaps using mailing lists as a metric until usage picks up enough to
measure jobs and such.
Jon Harrop
> It seems that everyone has put Scala in their top 5 :-). So either we
> were all introduced to the this group through the Scala community, or
> we're in for some glorious objected oriented functional times. I'd
> like to see a graph of the trends of these fledgling languages.
You can trend the number of registered installs of Debian packages:
Per Bothner
> Hard to narrow it down, but
>
> Scala
> Kawa
> Pnuts
> Talc -
> F3 - such a good name :)
Yes -certainly better than the current marketing-chosen
name: "JavaFX Script".
> Re: Kawa, I'm specifically interested in the reusable language
> infrastructure that underlies it, which seems like a big plus--oddly
> enough, even used in one attempt for Perl on the JVM, see -
> http://www.ebb.org/bkuhn/writings/technical/thesis/node40.html for
> example. I think it's a good example of the sort of learn-and-share
> approach by language designers and developers which in the long run is
> as important, if not more important, than bragging right about how
> many languages run on the JVM.
We did consider using Kawa for the JavaFX Script compiler:
I did some preliminary porting, and Chris Oliver was in favor of
the idea, but we were overruled by management, who said we should
base it on javac. (I'm not saying management was wrong in this -
while we could probably have progressed faster using Kawa, there
were good practical reasons for going the javac route.)
--
--Per Bothner
p...@bothner.com per.b...@sun.com http://per.bothner.com/
David MacIver
>
> On Thursday 24 April 2008 21:39:56 Daniel Green wrote:
> > It seems that everyone has put Scala in their top 5 :-). So either we
> > were all introduced to the this group through the Scala community, or
> > we're in for some glorious objected oriented functional times. I'd
> > like to see a graph of the trends of these fledgling languages.
>
> You can trend the number of registered installs of Debian packages:
>
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=scala&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
Or you could if the idea of using Debian's package management for
anything Java based was worth taking seriously.
Jim White
> For my CommunityOne talk...how about everyone posts five "interesting"
> JVM language projects...
Groovy
Kawa
ANTLR
Scala
And for my abandonded and perhaps most lamented:
MLj (the original source for F#)
Jim
Randall R Schulz
> Charles Oliver Nutter wrote:
> > For my CommunityOne talk...how about everyone posts five
> > "interesting" JVM language projects...
>
> Groovy
> Kawa
> ANTLR
> Scala
Wow. It's fascinating that someone would list both Groovy and Scala! The
former is a cowboy language that is poorly constrained and ill-defined
while the latter is strongly founded in theory and precisely defined.
Or, as I've occasionally opined, Groovy is scruffy and Scala is neat.
And ANTLR? I use it, but it hardly represents either a JVM-specific
language or, really, a programming language at all, in any conventional
sense.
> ...
>
> Jim
Randall Schulz
raybaq
Couldn't resist delurking to mention the JVM language I'm working on:
JoyJ (Joy in Java, available at http://appforge2.apc.edu.ph/gf/project/joyj/scmsvn/),
an interpreter for the concatenative programming language Joy (http://
www.latrobe.edu.au/philosophy/phimvt/joy.html). I used ANTLR in
developing the interpreter.
Ray Baquirin
Jim White
> On Thursday 24 April 2008 17:08, Jim White wrote:
>
>>Charles Oliver Nutter wrote:
>>
>>>For my CommunityOne talk...how about everyone posts five
>>>"interesting" JVM language projects...
>>
>>Groovy
>>Kawa
>>ANTLR
>>Scala
>
> Wow. It's fascinating that someone would list both Groovy and Scala! The
> former is a cowboy language that is poorly constrained and ill-defined
> while the latter is strongly founded in theory and precisely defined.
> Or, as I've occasionally opined, Groovy is scruffy and Scala is neat.
Groovy has the right ideas to become a prototype for Java 3. Also I use
it a whole lot right now (<http://www.ifcx.org/>). But, alas, the
current implementation and lack of such things as a specification and
support for static type inference no doubt make it hard for most folks
to see a diamond in the rough.
Scala has the right machinery for implementing a prototype for Java 3.
Alas it suffers from the problem of other JVM languages like JRuby,
Jython, and JavaFX in that it has gratuitous syntax deviation from Java
for features that are the same as in Java.
So I'm looking ahead to Groovy 2 and thinking of getting the compiler
guts from Scala or Kawa (which for ten years I've said is the best thing
for Java no one has ever heard of...).
I'll be around for JavaOne (giving a lightning talk on IFCX Wings on
Monday) and I'm sure we'll be having many dandy discussions about such
things.
> And ANTLR? I use it, but it hardly represents either a JVM-specific
> language or, really, a programming language at all, in any conventional
> sense.
It is a classic programming language as soon as you do anything other
than specify a simple recognizer. Or perhaps it would be more accurate
to say that you must weave in code using such a conventional programming
language to do cool things. And not being JVM-specific (although that
is it's "native" platform) hardly seems like a bad thing...
Jim
Charles Oliver Nutter
> Scala has the right machinery for implementing a prototype for Java 3.
> Alas it suffers from the problem of other JVM languages like JRuby,
> Jython, and JavaFX in that it has gratuitous syntax deviation from Java
> for features that are the same as in Java.
Them's fightin words!
Syntax is important, but I don't think in the way that Scala's using it.
Of course I'm biased, but Ruby's syntactic "endulgences" appear to be
focused on making programming more fun...making programmers happier. I
think that alone deserves a lot of credit. Most languages focus on "one
way to do anything" or "we're easy for X programmers to learn". Matz
focused on making Ruby "fun". We could all use that kind of gratuity in
our languages.
And Ruby is far more flexible and capable than Java. It's just slow (so
far).
- Charlie
Randall R Schulz
> Randall R Schulz wrote:
> > On Thursday 24 April 2008 17:08, Jim White wrote:
> >>Charles Oliver Nutter wrote:
> >>>For my CommunityOne talk...how about everyone posts five
> >>>"interesting" JVM language projects...
> >>
> >>Groovy
> >>Kawa
> >>ANTLR
> >>Scala
> >
>
> > And ANTLR? I use it, but it hardly represents either a JVM-specific
> > language or, really, a programming language at all, in any
> > conventional sense.
>
> It is a classic programming language as soon as you do anything other
> than specify a simple recognizer.
Sorry, but is is in no way and by no definition a "classic programming
language" of any sort.
> ... And not being JVM-specific
> (although that is it's "native" platform) hardly seems like a bad
> thing...
It wasn't a value judgment, but a reaction to the fact that it was
listed in response to a request for JVM-specific languages. While the
ANTLR processor itself runs in the JVM, it is agnostic as to the
language of the code it generates.
> Jim
Randall Schulz
Charles Oliver Nutter
It wasn't a request for JVM-specific languages...just JVM languages. In
other words, F# might be great, Boo may be awesome, but they're not
really on-topic for my talk. But Python, Ruby...perfect example cases.
- Charlie
Jim White
Obviously syntax preference is a matter of taste and there's surely no
accounting for that (or fighting over it).
As a long-time Lisper (and Forther from before that) I'd just as soon
the language say as little as possible about syntax and let users make
up whatever they like. But that has certain well-known problems and is
not going to be a mainstream approach for "enterprise" application
developers any time soon.
My dismissal of languages on the basis of their syntactic choices is
specifically with regard to the best scripting language for Java
*developers* and also which might become a prototype for Java 3 (as GJ
was for Java 5 (2?)). For both of those purposes, a language that
doesn't support Java syntax for features that are already in Java is a
non-starter.
As far as the smackdown goes, Groovy runs a lot slower than Java (though
faster than Ruby) and that really has little significance. Groovy is
tons faster to *write* than Java and a whale load more fun (certainly as
fun as Ruby :->)!
Jim
Martin Probst
if you care for "really different languages", there is XSLTC which
compiles XSL transformations into bytecode, as far as I know, but it's
not really under active development.
And there are at least two XQuery implementations that compile to Java
or bytecodes, by Per Bothner (hello :-)) and by Michael Kay of Saxon
fame. XQuery is a purely functional domain specific language (XML
querying), so this might be interesting to people.
I'd also hesitate to call ANTLR a programming language, as the
grammars are not turing complete (I think), but it's certainly a
domain specific language that compiles to Java code. And maybe they
are interesting because they have some really different problems with
what they do. For example, they kept running into class file, method
size, etc. limits for their DFAs and other generated code.
My list would be JRuby, Scala, Duby (indeed), XQuery, ANTLR.
Regards,
Martin
Rémi Forax
It's not that complex to have a clean separation between the specification
of the grammar and the action to execute when you reduce.
> My list would be JRuby, Scala, Duby (indeed), XQuery, ANTLR.
>
> Regards,
> Martin
>
Rémi
Guillaume Laforge
My turn to play the game :-)
1) JRuby or Jython or Rhino (pick the one you like best)
Showing how one can "port" an existing scripting and/or dynamic
language to the JVM
2) Groovy
Showing how we can "derive" a dynamic language using the Java 5
grammar to make it look like Java, but dynamic semantics and its own
feature set beyond what Java has to offer
3) One functional language of choise, but I'm not really qualified to
say which one is the most interesting there :-(
4) Scala
Showing another statically typed language for the JVM which marries
functional and full OO language paradigms.
5) Ng
Not only because John is my friend ;-) but because it's a very
interesting and promising experiment to create the fastest MOP
possible on a JVM which hasn't been designed to support dynamic
languages
I think these 5 ideas would cover some interesting ground, interesting
paradigms and challenges.
Guillaume
On Thu, Apr 24, 2008 at 7:53 PM, Charles Oliver Nutter
<charles...@sun.com> wrote:
>
> For my CommunityOne talk...how about everyone posts five "interesting"
> JVM language projects. This can certainly include languages that aren't
> under active development right now or that don't have a large following.
> I just want to gather a list of languages that "we implementers" and JVM
> language enthusiasts think the world should know about (and which are
> good examples of the work we're doing on VM).
>
> These do not represent languages you think are the "best" or "most
> important" or anything like that, so be honest. It's just going to be
> added to a flat list, probably in alphabetical order.
>
> Here's my top five "interesting" language projects:
>
> JRuby - pushing the bounds of class generation and dynamic invocation
> perf, as well as pulling a whole other platform into the JVM ecosystem
>
> Groovy - providing almost all Java language features and two-way
> integration in addition to many (most?) dynamic language features found
> in languages like Ruby.
>
> Jython - A second opportunity to pull a whole platform into the JVM
> world, and a very receptive Python community that doesn't hate anything
> with a J in it
>
> Scala - Not obvious? Solid integration with Java and object/functional
> goodness.
>
> Duby - Ok, I'm biased, but if I ever get time to work on it Duby could
> marry Ruby syntax with a full complement of Java features and local type
> inference. Exactly what I've been looking for.
>
> - Charlie
>
> >
>
--
Jochen Theodorou
Groovy, Scala, JRuby, Rhino, Kawa, Nice.... take 5 of them.
there is a difference in quality between them. I like Scala, Nice, Rhino
and Kawa not because of their implementation and integration, but
because of the ideas they bring to the JVM. Sadly Nice seems to be dead
meat, well that's another story. I also like very much some ideas in
Scala. And even though I am a Groovy developer I am not a dynamic
language fanatic. A well made static language can be much fun and if you
need certain dynamic features you emulate them.
as for Groovy... I am quite biased here of course.
and JRuby... I must say I never used it really. Groovy has so many equal
or nearly equal concepts with Ruby, that the language is most of the
time no reason to us it over Groovy for me. The interesting part in
JRuby is the implementation.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
easieste
implement on the JVM:
Clojure
Kawa
Jython
ABCL
JRuby
And I would put 'Fortress' up there, but I don't know if Sun has
released easily inspectable source code yet.
Mark Evenson
David MacIver
> And I would put 'Fortress' up there, but I don't know if Sun has
> released easily inspectable source code yet.
They have, but Fortress probably shouldn't really be considered a JVM
language. If it stays on the JVM it will probably be because it failed
as a project. The JVM version is only the reference implementation and
is kinda unsuitable for their goals.
Jon Harrop
Can you elaborate on why the JVM is unsuitable for their goals?
David MacIver
>
>
> On Friday 25 April 2008 12:08:25 David MacIver wrote:
> > On Fri, Apr 25, 2008 at 11:49 AM, easieste <evenson...@gmail.com>
> wrote:
> > > And I would put 'Fortress' up there, but I don't know if Sun has
> > > released easily inspectable source code yet.
> >
> > They have, but Fortress probably shouldn't really be considered a JVM
> > language. If it stays on the JVM it will probably be because it failed
> > as a project. The JVM version is only the reference implementation and
> > is kinda unsuitable for their goals.
>
> Can you elaborate on why the JVM is unsuitable for their goals?
Frankly, I'm not sure. But they've said in the past that their intent
is not to remain on the JVM - the version currently running on it is
just an interpreter as far as I know. I think part of it is that they
want much more tight control over exactly what work goes on what core,
which the JVM's threading model doesn't really allow at the moment.
Weiqi Gao
> On Friday 25 April 2008 12:08:25 David MacIver wrote:
>> On Fri, Apr 25, 2008 at 11:49 AM, easieste <evenson...@gmail.com>
> wrote:
>>> And I would put 'Fortress' up there, but I don't know if Sun has
>>> released easily inspectable source code yet.
>> They have, but Fortress probably shouldn't really be considered a JVM
>> language. If it stays on the JVM it will probably be because it failed
>> as a project. The JVM version is only the reference implementation and
>> is kinda unsuitable for their goals.
>
> Can you elaborate on why the JVM is unsuitable for their goals?
This interview with Guy Steele about Fortress might answer your question:
http://se-radio.net/podcast/2006-11/episode-36-interview-guy-steele
Randall R Schulz
> Randall R Schulz wrote:
> > On Thursday 24 April 2008 19:47, Jim White wrote:
> >
> >> ... And not being JVM-specific
> >> (although that is it's "native" platform) hardly seems like a bad
> >> thing...
> >
> > It wasn't a value judgment, but a reaction to the fact that it was
> > listed in response to a request for JVM-specific languages. While
> > the ANTLR processor itself runs in the JVM, it is agnostic as to
> > the language of the code it generates.
>
> It wasn't a request for JVM-specific languages...just JVM languages.
> In other words, F# might be great, Boo may be awesome, but they're
> not really on-topic for my talk. But Python, Ruby...perfect example
> cases.
Well, I'm not sure exactly what distinction you're drawing, but ANTLR is
neither a JVM language nor a programming language in any but a very
narrow and specialized sense. It does define a language with which you
communicate your specifications to it, but that's essentially true of
all computer programs that accept input.
> - Charlie
Randall Schulz
Ola Bini
so I would call Antlr's grammar specifications a data definition
language, but not a programming language.
--
Ola Bini (http://ola-bini.blogspot.com)
JRuby Core Developer
Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
Practical JRuby on Rails (http://apress.com/book/view/9781590598818)
"Yields falsehood when quined" yields falsehood when quined.
Jim White
In what way is ANTLR not Turing Complete? You can most assuredly
implement a complete Turing Machine in ANTLR for the actions and
semantic predicates are most certinly part of the language. For folks
who only use ANTLR to generate an analyzer and link it to an external
program (I can see how they might be unaware of the rest of it
capabilities. But it is not at all necessary to use ANTLR that way.
You can simply write your whole compiler or whatever other application
in ANTLR and be done with it. Now ANTLR isn't so interesting if you're
not processing an input stream or tree, but that doesn't prevent you
from running arbitrary code on an empty input.
So if you're all still objecting to the idea of "ANTLR" being an
interesting JVM language (as though somehow the Java parts of the .g
file aren't "ANTLR"), I'll change my vote to "ANTLR/Java v3".
Of course Groovy gets rather less interesting if you drop the Java
syntax bits. Particularly when that is one of the key aspects that
makes it so compelling over otherwise comparable languages like JRuby,
Jython, JavaFX, and Scala.
Jim
Ola Bini
language. If it were part of the language, the parser would be able to
recognize syntax errors inside the actions. But actions in Antlr are
almost as opaque as the comments.
Antlr is a compiler, according to the definition of a compiler, but the
input language is not a full programming language.
> So if you're all still objecting to the idea of "ANTLR" being an
> interesting JVM language (as though somehow the Java parts of the .g
> file aren't "ANTLR"), I'll change my vote to "ANTLR/Java v3".
>
> Of course Groovy gets rather less interesting if you drop the Java
> syntax bits. Particularly when that is one of the key aspects that
> makes it so compelling over otherwise comparable languages like JRuby,
> Jython, JavaFX, and Scala.
>
Of course, the Java syntax bits are an integral part of the Groovy
language, in comparison to Antlr.
> Jim
Michael
port a language to the JVM. Actually, maybe that would make it a good
topic to talk about.
-- Michael
Attila Szegedi
>
> I have to vote against Rhino! It would be a good example of how to NOT
> port a language to the JVM. Actually, maybe that would make it a good
> topic to talk about.
Definitely. Care to elaborate?
Attila.
>
>
> -- Michael
rssh
May be it takes sense to speak about 'concept dimensions'.
From 'well-known concepts':
scripting/ Groovy, JavaFX, JavaScript
functional/ Scala, Hascel (business objects has java
implementation as .. CAL)
logic: jProlog
templating: Velocity, JSP
to exotics or relative new concepts:
term rewriting: /TermWare, Tom
or reimplementation of known languages
Axiom C, Jython, JRuby
(And yes - I work on TermWare ;) )
Randall R Schulz
> May be it takes sense to speak about 'concept dimensions'.
>
> From 'well-known concepts':
>
> scripting/ Groovy, JavaFX, JavaScript
What is the working definition of a "scripting" language?
> functional/ Scala, Haskel (business objects has java
> implementation as .. CAL)
> logic: jProlog
> templating: Velocity, JSP
Freemarker deserves to be included in this group, to be sure. And GSP is
quite nice, though Groovy-specific.
> to exotics or relative new concepts:
> term rewriting: /TermWare, Tom
Tom operates as a Java source-to-source transformation, so technically
it's not a JVM language, right? It arguably has more in common with
ANTLR than with any of the many languages that directly target the JVM.
> or reimplementation of known languages
> Axiom C, Jython, JRuby
>
>
> (And yes - I work on TermWare ;) )
OK, so I had to look up TermWare to see what it was about, and the only
thing I can say is, why couldn't I find this when I went looking for
rule-based rewriting software? I think you guys need to do more to gain
some visibility!
Randall Schulz
Thomas E Enebo
I think this is a nice breakdown....Individual languages in each area
subject to taste...
And you are the first person to mention the whole Prolog/inference
dimension of languages :)
-Tom
--
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: en...@acm.org , tom....@gmail.com
Randall R Schulz
> On Apr 25, 7:36 pm, Randall R Schulz <rsch...@sonic.net> wrote:
> > On Friday 25 April 2008 09:26, rssh wrote:
> > >
> > > scripting/ Groovy, JavaFX, JavaScript
> >
> > What is the working definition of a "scripting" language?
>
> Long - get Ousterhout's original 1990 USENIX paper
> http://citeseer.ist.psu.edu/ousterhout90tcl.html
> and change C to Java in item 5
Thanks, I'll check that out.
> Or, may be c2.com definition:
> http://c2.com/cgi/wiki?ScriptingLanguage (it's morer accurate than
> wikipedia)
>
> ...
>
> > > to exotics or relative new concepts:
> > > term rewriting: /TermWare, Tom
> >
> > Tom operates as a Java source-to-source transformation, so
> > technically it's not a JVM language, right? It arguably has more in
> > common with ANTLR than with any of the many languages that directly
> > target the JVM.
>
> No - Tom 2.x is extension of Java. It is Java class + rule/rewriting
> matching.
Huh? I'm using Tom 2.5, and you have to write external type and
constructor definitions in Tom's definition language and then run
augmented Java programs through the Tom translator to get ordinary Java
source you can compile.
> ...
>
> > OK, so I had to look up TermWare to see what it was about, and the
> > only thing I can say is, why couldn't I find this when I went
> > looking for rule-based rewriting software? I think you guys need to
> > do more to gain some visibility!
>
> ...
>
> //Home page is http://www.gradsoft.ua/products/termware_eng.html
> (It's strong enough to implement Java Partial evaluator.)
Yes, obviously I found it.
Randall Schulz
rssh
On Apr 25, 8:26 pm, Randall R Schulz <rsch...@sonic.net> wrote:
> On Friday 25 April 2008 10:17, rssh wrote:
>
> > On Apr 25, 7:36 pm, Randall R Schulz <rsch...@sonic.net> wrote:
> > > On Friday 25 April 2008 09:26, rssh wrote:
> > > > ...
>
> > > > scripting/ Groovy, JavaFX, JavaScript
>
> > > What is the working definition of a "scripting" language?
>
> > Oh - interesting question. I'm afraid I don't know short definition.
> > Long - get Ousterhout's original 1990 USENIX paper
> >http://citeseer.ist.psu.edu/ousterhout90tcl.html
> > and change C to Java in item 5
>
> Thanks, I'll check that out.
>
>
>
> > > > to exotics or relative new concepts:
> > > > term rewriting: /TermWare, Tom
>
> > > Tom operates as a Java source-to-source transformation, so
> > > technically it's not a JVM language, right? It arguably has more in
> > > common with ANTLR than with any of the many languages that directly
> > > target the JVM.
>
> > No - Tom 2.x is extension of Java. It is Java class + rule/rewriting
> > matching.
>
> Huh? I'm using Tom 2.5, and you have to write external type and
> constructor definitions in Tom's definition language and then run
> augmented Java programs through the Tom translator to get ordinary Java
> source you can compile.
>
source/source transformation (?)').
//It's because I know about Tom applications in source/source
transformations ;)
From other side -- I think that language which compiled to Java
source (and then
to JVM) technically is JVM language, because program on such language
are runs in JVM by default.
Attila Szegedi
> What is the working definition of a "scripting" language?
I really love Larry Wall's take on it:
<http://www.perl.com/pub/a/2007/12/06/soto-11.html>
>> functional/ Scala, Haskel (business objects has java
>> implementation as .. CAL)
>> logic: jProlog
>> templating: Velocity, JSP
>
> Freemarker deserves to be included in this group, to be sure.
Well spotted. Thank you, Randall :-)
Attila.
David Huebel
>
> On Friday 25 April 2008 10:17, rssh wrote:
> > Oh - interesting question. I'm afraid I don't know short definition.
> > Long - get Ousterhout's original 1990 USENIX paper
> > http://citeseer.ist.psu.edu/ousterhout90tcl.html
> > and change C to Java in item 5
As well as changing C to Java, change the paradigm from procedural to
OO. To control or customize a procedural system, it is natural to
write "scripts," little procedures that call system procedures. This
kind of traditional procedural scripting is not very useful when
working with an OO system because the system's control and
customization hooks are based on OO concepts, not procedural ones. To
control and customize an OO system you have to create objects and call
methods. A scripting language for a Java-based system must let you
call instance methods, instantiate classes, subclass existing classes,
and implement interfaces.
-David
Arco Oost
For me there is just the one: Scala, the marriage of object oriented
with functional is awesome.
Arco
rssh
programs near 1000 LOC each)
was not about Scala itself, but about Java:
'duke typing, closures and multi-line strings must be included to
next Java version'.
Rich Hickey
On Apr 24, 1:53 pm, Charles Oliver Nutter <charles.nut...@sun.com>
> For my CommunityOne talk...how about everyone posts five "interesting"
> JVM language projects. This can certainly include languages that aren't
> under active development right now or that don't have a large following.
> I just want to gather a list of languages that "we implementers" and JVM
> language enthusiasts think the world should know about (and which are
> good examples of the work we're doing on VM).
>
think people might find Clojure interesting:
- Clojure is a modern implementation of Lisp, the grandfather of
dynamic languages. Many of the concepts underlying Ruby, Python, Java
etc came from Lisp. If you've looked at Common Lisp or Scheme before,
you might find that Clojure is substantially easier to read and write,
with support for vector and map literals in addition to lists, and far
fewer parentheses. But Clojure does not give up Lisp's code-as-data
philosophy and the powerful macro system it enables.
- Clojure was written for the JVM. As such it can have deeper
integration with the Java framework, and the JVM type system. In fact,
Clojure does not implement its own type system on top of the JVM's. So
Clojure Strings are Java Strings, Clojure collections implement
java.util.Collection, Clojure's sequence library works with any Java
Iterable etc. Clojure's interface to Java uses no wrapper classes.
- Clojure is compiled to JVM bytecode, and as such is subject to the
performance optimizations of HotSpot etc. Clojure supports optional
type hints that allow calls to Java that avoid reflection, and run as
fast as Java.
- Clojure is a functional language, i.e. its core data structures are
immutable. It reflects, in many ways, a rejection of structuring
systems using a web of interconnected mutable stateful objects (i.e.
traditional OO). Functional programs are more robust, easier to test
and easier to understand. If you've read the excellent 'Java
Concurrency in Practice' you've seen how often it recommends
immutability, but, without a good set of efficient immutable data
structures, it's very difficult advice to follow. When using Clojure,
you are automatically following that advice all the time.
- Clojure was designed with concurrency in mind, leveraging Java's
well defined memory model and rich java.util.concurrent library to
provide robust facilities for doing concurrent programming, including
a software transactional memory system, an asynchronous agent system
and dynamic thread-local variables, which together make writing
correct multithreaded programming much easier than in Java.
Clojure was designed to tackle the problems for which you might
ordinarily use Java. It is one of the few JVM languages providing
concurrency support at a higher level than the native locks. It has
all of the fun and fast aspects of a dynamic language with a REPL,
plus compiled performance, functional robustness, multithread
awareness, Lisp macro power, and all of the Java framework at your
fingertips.
Rich
Charles Oliver Nutter
> Hi,
>
> Couldn't resist delurking to mention the JVM language I'm working on:
> JoyJ (Joy in Java, available at http://appforge2.apc.edu.ph/gf/project/joyj/scmsvn/),
> an interpreter for the concatenative programming language Joy (http://
> www.latrobe.edu.au/philosophy/phimvt/joy.html). I used ANTLR in
> developing the interpreter.
You should start another thread with an overview of the language and the
implementation's design. We'd love to hear about any implementation
challenges you've run into.
- Charlie
Charles Oliver Nutter
>> functional/ Scala, Haskel (business objects has java
>> implementation as .. CAL)
>> logic: jProlog
>> templating: Velocity, JSP
>
> Freemarker deserves to be included in this group, to be sure. And GSP is
> quite nice, though Groovy-specific.
I don't really consider either JSP or GSP to be their own languages
since they're just one language stuffed inside markup syntax.
- Charlie
raybaq
(homepage: http://www.latrobe.edu.au/philosophy/phimvt/joy.html) is a
purely functional concatenative language. The reference
implementation is in C; JoyJ is my attempt at an implementation in
Java. The first release, JoyJ-0.06, (http://appforge.apc.edu.ph/
projects/joyj/) was written in NetRexx and stored Joy data objects as
Rexx strings. To process e.g. a set meant parsing out each word and
treating it as an element--easy enough, but what about a string that
represented a list (which could contain another list)?
So, the next (latest, JoyJ-0.3) release uses JSON as the data object
format. I could perhaps have stayed with NetRexx but there seemed to
be no way to use Java generics from NetRexx, so it's now all Java with
an "outer" interpreter generated using ANTLR.
I haven't done any testing though so maybe changing the data
representation was "premature optimization" ?
I guess that means I do have to get a testing framework in place.
BTW, thanks to everybody on the list--I'm learning something new
everyday.
Best,
Ray
On Apr 30, 3:23 am, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> > Hi,
>
> > Couldn't resist delurking to mention the JVM language I'm working on: