Lambda the Ultimate

It is supposed to be statically typed, but it looks like it is not really ready yet. The language is still interpreted at the moment, not compiled, so any speed advantages of static typing are lost.
Also the netbeans and eclipse plugins look to be very early in development. It will probably be a long time before they are complete.

Here is my earlier post here about F3: http://lambda-the-ultimate.org/node/1998

Oops, that's a typo. I've fixed it.

My very first post on LtU, and I screw it up. I meant to post the above under the openfix topic. I meant to say that it was my reading of the openfix documentation that reminded me of the Declarative-Procedural approach.

This is supposed to be a competitor to Flash. I don't know where you're getting J2EE from. This is standard Java technology, just like there's other languages that run on top of the JVM with their own libraries.

JavaFX seems to have multiple goals: I've heard it described as a competitor to Flash/Flex, a competitor to Microsoft's Silverlight, and as an "AJAX killer". It was the latter statement that made me think that JavaFX was going to be promoted as the client-side component of J2EE apps, but maybe I'm getting ahead of myself.

Really, I'm glad when anyone tries to write a new, useful programming language, even Sun. I'm just worried about vendor lock-in issues, even when the technology is open source. I don't want to be in the position where I say "JavaFX is great for developing client-side interfaces, but that means that all my server-side code has to be in Java too". I want interoperability, and as far as I know Sun doesn't seem to be very interested in this. It's this all-or-nothing attitude that I dislike.

I don't want to be in the position where I say "JavaFX is great for developing client-side interfaces, but that means that all my server-side code has to be in Java too". I want interoperability, and as far as I know Sun doesn't seem to be very interested in this. It's this all-or-nothing attitude that I dislike.

How does Sun maintain a "you can only talk to Java server applications" attitude with regards to applets or Webstart?

Really, I'm glad when anyone tries to write a new, useful programming language, even Sun. I'm just worried about vendor lock-in issues, even when the technology is open source.

That lock-in term gets thrown around too much. You're locked into whatever you use.

is open source.

The wire protocols are documented.

There is no "secret sauce" involved.

Nor any patents or other legal impediments.

Nobody has a gun to your head telling you that if you use X you must also use Y--at least not in the Java world.

The only lock-in is that if you want nonstandard kit, you may have to look harder to find it or write it yourself.

Nor any patents or other legal impediments.

The Apache people don't agree. Last month they wrote an Open Letter to Sun because they were having trouble with certain restrictions. From the Open Letter FAQ:

Q : What is "necessary IP" and why is this important that compatible implementations receive it?

A : "Necessary IP" is the IP - usually patents - that cannot be technically avoided when implementing the specification. This is important because it prevents anyone from joining an expert group and gaining the ability to demand royalties from implementors or users of the specification. This is one of the main features of the JCP that makes the specs the JCP produces "open specifications".

[..]

To give a concrete example from the Sun / Apache dispute, if Apache accepted Sun's terms, then users of a standard, tested build of Apache Harmony for Linux on a standard general purpose x86-based computer (for example, a Dell desktop) would be prevented from freely using that software and that hardware in any application where the computer was placed in an enclosed cabinet, like an information kiosk at a shopping mall, or an X-ray machine at an airport.

though the crux of the issue is branding, if I understand correctly. Apache isn't prevented in this case from interacting with parts of Java ecosystem. Their issue is that there are legal restrictions in their ability to use the "Java" trademark on the result.

However, I could be mistaken. :)

Their issue is that there are legal restrictions in their ability to use the "Java" trademark on the result.

There's also the issues about patents built into the specs, as I quoted from the FAQ. At any rate, this is getting pretty deep. The main point is yes, issues do remain if Apache publically declared they are having trouble giving the world a free/open/non-GPL implementation of Java.

I give a lot of credit to Sun for as far as they've gone, but they aren't quite there yet. At least they aren't grumbling about Linux and patents like some other 800-pound gorilla I know :)

I never understood what the merit of an eval function is. I've only seen it used in horrific cases where people are evaluating user supplied code on the server side and the like. Can anybody enlighten me please?

...allegedly. :)

One common metaprogramming technique is of course to compose a code fragment, either as text or in some other symbolic representation (for those languages which can easily represent their own syntax as data structures), and then pass it to an interpreter for evaluation. (And some languages operate almost entirely on this premise).

I say "allegedly", because there are many other ways to to metaprogramming that are more easily reasoned about by compilers and such.

* Macros and term-rewriting engines
* Reflection and MOPs
* Higher-order functions and types

The $1,000,000 question is whether or not eval() (by which I assume we all mean a function which interprets code potentially supplied at runtime) is truly necessary. Many find it convenient--and it is--OTOH, many languages don't have it and seem to be quite useful regardless. Many eval() implementations aren't particularly secure--even if run on an interpreter/VM which protects the language's own abstractions from ill-formed or hostile code; there is a lot of potential for mischief. The same of course applies if you download and run a compiled app from an untrusted source.

MSP (especially MetaML or MetaOCaml style) is another to add to the list. Similar to the quote/eval style of Scheme (and other Lisps) but type safe.

As it works via a 'code literal' rather than strings so it's safer but can still be as tricky and confusing to actually use in anger. Although some of the issues can probably be helped with better syntax.

Compile time reflection (safer, potentially faster but less powerful than runtime reflection) is a interesting (AFAIK conservative) extension. Proper macros can be encoded within MSP as well.

Here's the concrete use case:

I'm curious about what role JavaFX will play in scripting for cell phones, something that I have a stake in myself with my simple, humble Hecl language (hecl.org). Since it's an interpreter, 'eval' was very natural to have as part of the language. This lets you do things like the following:

User downloads simple Hecl application, which can go to a site and download new applications, fetch them, run them and store them if needs be.

(As an aside, Paul Graham seems to have invested in a company that does something similar: see Tsumobi:

http://startupmeme.com/2007/03/19/ycombinator-a-force-to-reckon-with-a-model-to-replicate/
)

User downloads simple Hecl application, which can go to a site and download new applications, fetch them, run them and store them if needs be.

Why does this need eval? You only need dynamic linking and first-class modules/components. A number of languages provide this in some form, e.g. Java, Oz, Alice ML (disclaimer: this list is incomplete and biased :-)). Incidentally, the latter even provides eval, but I have only seen one real use case for it yet: the implementation of the interactive toplevel.

J2ME is much more constrained than regular Java, so you don't get the opportunity to load things up like that - at least in older versions. Hecl's J2ME runtime comes in at around 64K, and that needs to be trimmed a bit for some older phones, so you don't have a lot of space to dedicate to being 'fancy', either.

As you say also, eval lends itself to making interactive applications quite well.

With eval you are, obviously, interpreting a language. Normally you only want to interpret some subset of the entire language. In your example you wouldn't expect the user code to encompass the entire host language. So clearly you can write a custom interpreter for whatever you subset you choose, and this will be more secure. However it isn't necessarily the most economic solution, and it may not be the fastest either. So eval is a handy tool for when you have little time or a poor infrastructure.

Javascript is a great example of this. Javascript interpreters are really mind-bogglingly slow. When writing an AJAX application you want to control the Javascript interpreter on the client's web browser. It is often much much faster to just squirt code at the browser and use the built-in eval than to use a custom Javascript interpreter.

Personally, I have seen it used mostly in templating systems, where a server-side program transforms, for instance, mixed html and code into an object with complex behavious generating the final html output. Think php, jsp, embedded perl etc. Drupal itself, which this site runs on, uses complex templates with embedded php. Having an 'eval' handy lets you use the main application language where you would normally use an ad-hoc minilanguage. Of course, as others have pointed out, this may be too great a power, needing the obligatory responsibility and sometimes leading to security nightmares.

Cheers

Antonio

As far as I can tell, this is only sugar for maps and folds for lists/arrays. I haven't seen any reference to JavaFX having any binding to sql like LINQ.

As far as I can tell, LINQ provides convenient syntax for a code tree that the database vendors need to interpret. The part of LINQ that query in-memory collections might syntactically have a bit in common with the way JavaFX updates arrays, but I can't see any other relation.

The three big advantages in JavaFX over Java seems to be the binding mechanism, object-literal syntax and local type inference(?).