Slashdot Mirror

The CLR like the JVM can host other languages, there is even a lisp for it ( http://clojure.org/clojureclr ). I am not that familiar with the CLR but I think that only "system languages" can't really be implemented in it.

Tail Call Optimisation is not implemented in Clojure, and the reason given in the documentation is precisely that interoperability with Java prevents this. Instead there's a recur special form, which, in my opinion, is a bit of an ugly hack.

Java is moving into archaic irrelevance faster than ever. That is, the language itself.

The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.

Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.

Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.

I encourage you to test drive the languages that sound interesting. Choose a small slice of a problem (parsing & reformatting a *.CSV file perhaps); something small enough that you solved it with < 1000 lines of C code. Then try coding up the same with Python and one or two more languages recommended here.

One of the scripting things I look for is portability. While Java itself is pretty awful for rapid development (at least for me Java is painfully verbose), if you want to piggyback on Java's virtual machines you can go a long way with Groovy, Clojure, and maybe Python (here's an interesting review of JVM languages). It turns out for my day job there is always a JVM in the environments I need to work in, so I look for easier languages to work with in that regard.

My current personal favorite is Clojure; great leverage, you get a lot of bang for your buck for a line of clojure vs. a line of Java or C.

Java and C# are not different languages. They are the same language - much more similar than, for example Medley Common Lisp and Franz Allegro Common Lisp, and those are two implementations which both conform to the same published specification. Java and C# have very slightly different syntax, and slightly different core libraries. But if you can read (or write) one you can read (or write) the other. The compilers work in very much the same way, and even the object code and virtual machines are similar.

Which isn't surprising. Microsoft based C# on its own implementation of Java, changing it (only) just enough to get around legal problems with Sun. It's a very sincere flattery. C# is slightly newer, so it has slightly less legacy cruft. Apart from that, you are comparing apples with apples here. If you want a more interesting comparison, compare Java/C# with Ruby, Python, Lua, JavaScript/EcmaScript or Clojure.

Clojure: http://clojure.org/

Don't think it's formally Google anymore.

Whatever happened to them? Didn't they at one time have a Java implementation?

IBM's Java work is now part of OpenJDK. How close OpenJDK is to Oracle Java and whether it shares this exploit I don't know (although the OpenJDK home page says they are '...based largely on the same code'), but if it does it should be patchable.

I'm not ready to give up on Java. It is not because I think it's the best, I still think C# beats it as a language, but at times when a client requires non-microsoft, it is my only choice for a modern language. Yeah, I know C++11, I've looked at it quite a bit, and it is better than it was, but as long as it needs header files, I don't put it into a modern language category.

I could happily give up Java, but I wouldn't willingly give up Clojure. There's more (and better) languages for the JVM than just Java.

Java was one of the first languages with a large standard API. It has nice documentation, but the language is barely better than C/C++. An ecosystem has developed around Java bytecode, however: languages like JRuby and JPython can run like Java and interface with Java code. There's also "groovy", a "modern" language built entirely around Java bytecode.

When talking about JVM language ecosystem, the two names that should always be named are Clojure - a modern Lisp dialect with emphasis on concurrency, and Scala - the king of the modern "kitchen sink" approach of programming language design.

Okay, that's a relief. I thought as much. So how do you feel about Clojure?

Learn Clojure with the help of Project Euler. After years of programming that made me feel like a grey bureaucrat, those two got me excited again.

Clojure is a modern LISP -- I have a former employer using it for real-time analytics work (where its transactional memory model made it easy to scale to very, very parallel machines -- the older version of the software written with traditional lock-based concurrency fell down at a fraction of the production load we needed to handle with most CPU cores sitting around waiting for locks.

The biggest thing that interests me, though -- programming in a LISP lends itself to what Rich Hickey calls "hammock-driven development" -- thinking deeply for a long time and then writing very few lines, as opposed to throwing a few Kloc of code at the wall and seeing what sticks. Properly used, modern LISPs are tremendously flexible and tremendously compact -- most of the code I write day-to-day is Python or Ruby, but a LISP's expressiveness is vastly greater than either of these newer languages, and I'm tremendously excited to see folks working on making LISPs practical again.

Clojure has excellent language design and parallelism and the team recently released ClojureScript. A video introduction can be found here.

Because they require several different kinds of completely alien thinking; knowing imperative programming is almost a disadvantage to learning functional programming. Also, most functional languages were too purist to allow actually getting much real work done - the libraries were usually very weak so every problem involved reinventing dozens of wheels. Clojure may have solved this problem - it isn't too purist and it can use all the Java libraries. It still requires a lot from the programmer, though perhaps less than the gain in power it provides.

What you want to have is already done by Clojure, another JVM language resembling LISP. All it's collections are immutable but changeable. If you change a collection, a new object is created which references the data from the old object and the changed data. Can't say anything about it's numerical performance though.

Really, who cares about how they implement lambdas in Java syntax. The language is already so goddamned ugly you have to wear a full body condom to write in it anyway. The great news is that native Java lambdas will likely provide some concrete benefits to Clojure - the only real reason for the JVM to exist, IMO.

And in fact there is Clojure http://www.clojure.org/ , giving you parallel lambda execution and macros. I'm not quite sure that the Lambda will ever make it into the Java standard. Not even the Generics are fully supported at a JVM level. Most of the Java designers still love classic for-loops and consider anything functional as 'strange and exotic programming style'.

http://clojure.org/rationale

My personal favourite being Clojure
http://clojure.org/

It has excellent Java interop.

This isn't your grandfather's JVM.

These days, Java is quite fast and efficient, and there are even a lot of different alternative VMs you can try. Sure, startup time isn't the best, and Swing is still a lumbering, over-engineered, ill-fitting albatross: but these problems don't matter for server applications.

IMHO, the best part is that you can write programs that run on the JVM in a dialect of Lisp and interact seamlessly with other code on the JVM.

The CLI is, of course, both multi-platform and multi-language. So is the JVM, even though it was designed around the Java language.

It's technically correct, but VM limits do play a part in this.

To give one simple example: JVM doesn't have tail calls. Consequently, any language that mandates them (e.g Scheme) has to go to great lengths to implement something like this on JVM, and it's outright impossible to implement it efficiently. Meanwhile, .NET has tailcalls, and F# (and virtually any other FP language implemented on .NET) relies on that. Compare it with Clojure, which had to add a special form of restricted recursion to the language, to provide at least some, limited way to do tailcalls.

To give another example, it is possible to write a fully ANSI C conformant compiler targeting .NET bytecode. The reason why it's possible is because CLR has lower-level primitives available for "managed but unsafe" code - data and function pointers, pointer arithmetic, unions, etc - enough to fully cover C/C++ data model. It's why VC++ can actually take any random C++ code, and produce a .NET assembly out of it. It won't necessarily be memory-safe, but it will run in a VM, and memory-safe C# code can then easily interop with it.

To give yet another example, neither JVM nor .NET provide any facilities to efficiently implement continuations (call/cc). The result is that a fully conformant Scheme implementation for either platform - like SISC for Java - has to roll out its own call stack, which obviously isn't anywhere as efficient as native stack.

Good grief. Homophone insanity. We've got Clojure doing interesting things in the language and concurrency space. Block support in C/Objective-C reinjecting "closures" into everyone's vocabulary. And now Google jumps in with "Closure" just to make sure that no one has any idea what anyone else is talking about...

Clojure is a lisp on the JVM designed for multi-threading. From:
    http://clojure.org/
"""
Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR ). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection. Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.
"""

So I'm going to trot out a different perspective; enough others will thrash through the personalities under discussion here. In my view, Mono is essentially irrelevant. Some folks will use it to bridge apps around platforms, instead of Qt or a handful of other approaches. Yawn. Internally, Microsoft has done some pretty neat things with their various implementations of the CLR (the VM underlying C#). This is unsurprising, as they're well capable of hiring some pretty bright folks. But I doubt that any of that will ever really inform the broader computing community.

In contrast, the JVM seems to be undergoing a renaissance. There's tons of programming language work on the JVM these days: Scala, JRuby, Clojure, Jython, etc. Each of these are bringing their own communities and problem domains to the JVM, and have already broken new ground in language implementation and design. As for new frameworks, there's scalable computing work going on under the Hadoop project (Google filesystem, Bigtable, and map-reduce for-the-rest-of-us) and the really interesting related framework Cascading. With the JVM as an interoperability platform, these languages and various new frameworks all get to be combined together in fascinating new ways.

I chose not to use the Erlang-style actor model for same-process state management in Clojure for several reasons:

• It is a much more complex programming model, requiring 2-message conversations for the simplest data reads, and forcing the use of blocking message receives, which introduce the potential for deadlock. Programming for the failure modes of distribution means utilizing timeouts etc. It causes a bifurcation of the program protocols, some of which are represented by functions and others by the values of messages.
• It doesn't let you fully leverage the efficiencies of being in the same process. It is quite possible to efficiently directly share a large immutable data structure between threads, but the actor model forces intervening conversations and, potentially, copying. Reads and writes get serialized and block each other, etc.
• It reduces your flexibility in modeling - this is a world in which everyone sits in a windowless room and communicates only by mail. Programs are decomposed as piles of blocking switch statements. You can only handle messages you anticipated receiving. Coordinating activities involving multiple actors is very difficult. You can't observe anything without its cooperation/coordination - making ad-hoc reporting or analysis impossible, instead forcing every actor to participate in each protocol.
• It is often the case that taking something that works well locally and transparently distributing it doesn't work out - the conversation granularity is too chatty or the message payloads are too large or the failure modes change the optimal work partitioning, i.e. transparent distribution isn't transparent and the code has to change anyway.

Erlang is meant for distributed computation, which is a grand overkill for most programs. See here: http://groups.google.com/group/clojure/msg/2ad59d1c4bb165ff Scala unlike Clojure did not embrace the importance of immutability to concurrency programming, which is why I think it's badly lacking. See here: http://clojure.org/state

Check out Clojure. The only programming language around that really addresses the issue of programming in a multi-core environment. It's also quite a sweet language besides that.

And I heard functional languages like Lisp/Haskell are good at these multi-core tasks, is that true?

It is true, because they privilege immutable data structures which are safe to access concurrently.

Only partly true. Even in pure functional languages like Haskell, the functional-programming dream of automatic parallelization is nowhere near here yet; in theory the compiler could just run a bunch of thunks of code in parallel, or speculatively, or whatever it wants, but in practice the overhead of figuring out which are worth splitting up has doomed all the efforts so far. It does make some kinds of programmer-specific parallelism easier; probably the most interesting experiments in that direction, IMO, is Clojure's concurrency primitives (Clojure's a Lisp-derived language with immutable data types, targeting the JVM).

Lisp, FWIW, doesn't necessarily privilege immutable data structures, and isn't even necessarily used in a functional-programming style; "Lisp" without qualifiers often means Common Lisp, in which it's very common to use mutable data structures and imperative code.

Real concurrency on the jvm: try clojure

Although I have been using Ruby and Lisp more the last few years, much of my business is based on Java

You might want to have a look at Clojure

Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

Who mentioned programming Java? Only your fouled-mouthed troll.

Cyberax was talking about running languages such as Python, Ruby or Lisp on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM.

Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark.

The JVM seems to have advanced to the point where other languages besides Java are targeting it as well. Two of the more popular seem to be Clojure and Jython. I suspect more will start appearing if JRE 7 adds better built-in support for compiling dynamic languages, as has been long discussed.

And, in the meantime, Java has come along, re-inventing and re-implementing tons of features from Lisp and Unix.

Not just tons of features, they accidentally the whole thing!

There is an easy introduction from a Java perspective.

Not quite mainstream and obvious as the pointless list presented in TFA, but I gotta add: Clojure

Clojure seems at first as Yet Another Lisp or Yet Another JVM Language or the general Yet Another New Programming Language, but once you scratch the surface you will discover it's an amazing engineering feat with groundbreaking design.

OK, so why is it so hard to create a hybrid language?

It's not hard, and there are plenty of them:

• Objective Caml
• F#
• Nemerle
• Scala
• Clojure

From the list above, OCaml is presently production-quality, and used rather widely. It also has a good performance profile, rivalring C/C++ with carefully written code. Of the others, the fastest-growing seems to be F# (mostly because Microsoft announced that they're making it into "Visual F#" and likely including it into Visual Studio 2010 alongside C# and VB as the third out-of-the-box .NET development language). Scala has a pretty large following in the Java land, so much so that some call for freeze of Java language spec for the sake of stability, and moving onto Scala for further language development.

Also, most modern dynamic languages (Perl, Python, Ruby, JavaScript) have many functional traits, and so do quite a few mainstream static ones (C#, VB).

You can also use Clojure, for a Lisp-like jvm language with macros.

If you're looking for a modernized lisp on the JVM, check out Clojure: http://clojure.org/
All the goodies of lisp, the JVM, and functional programming without all the bad outdated stuff. It's a very cool language.

If you don't know of it already, you might also wanna take a look at Clojure, a Lisp dialect that can either be interpreted or precompiled to .class files.

Have you had a look at Clojure? It is a Lisp dialect that runs on the JVM with good Java interop and has built-in support for STM concurrency.

This thread discusses the merits of the STM features of Clojure, a JVM language. It's another way to do lock-free concurrent programming on the JVM, using appropriate data structures.