A look at two new languages: Vala and Clojure
Some programming languages forge new ground, others are refinements of previously existing ideas, and still others tackle a specific problem in a new and better way. This article will look at two up-and-coming languages that are not yet as widely adopted as C, C++, or Java, but offer developers some intriguing benefits: Vala and Clojure. Vala is designed specifically to build native applications for the GNOME desktop environment, and Clojure brings the power of Lisp and functional programming to the Java Virtual Machine (JVM).
Vala
GNOME itself is written in C, but many of the higher-level libraries that make up the GNOME platform (such as GTK+ and Pango) make heavy use of the GLib and GObject frameworks, which implement a complete object system including types, messaging, classes, and all of the other components that make up a typical object oriented application program interface (API). GObject makes it possible to write object oriented GNOME applications in C, and also makes it simple to provide wrappers to GNOME for object oriented languages like C++ or Python.
While GObject makes object-oriented programming in C possible, it remains somewhat cumbersome. The GObject wrappers for other languages can be even worse, introducing yet another layer of dependencies which can include virtual machines of their own. Vala was created in an attempt to address these problems and make GNOME programming easier. Vala provides a C#-like syntax that integrates GObject features, but the valac compiler compiles to C output rather than assembly. The resulting C compiles normally with gcc, plus it can be distributed as source packages fully usable on platforms that do not have Vala installed. That allows the developer to use Vala's modern language features — dynamic type system, assisted memory management, and so on — while still making source releases compatible with C applications and libraries.
In addition to GLib and GObject, the Vala project produces bindings to the major GNOME libraries: GTK+, GDK, Cairo, SDL, GStreamer, D-Bus, GIO, and many more. In addition, several external projects provide their own bindings for Vala (such as Clutter), and there are third-party efforts to create bindings for other libraries, such as OpenGL. Plugins for Vala support are available for the Eclipse, Anjuta, and MonoDevelop IDEs, as well as for the editors Emacs, Vim, and GEdit. Val(a)IDE, still in development, is a dedicated Vala IDE written in Vala itself.
The latest release of Vala is 0.7.3, which went public on May 26, 2009. It is a bugfix release for the 0.7 series, which is intended to be the last development series before 1.0. The biggest change in the 0.7 series, according to developer Jürg Billeter, is to C header file generation. In previous releases, Vala would generate a .h header file for every .vala source file, which caused problems:
That change demanded making changes to the build system for existing Vala applications, but Billeter said it should be the last such headache for a while.
Vala 1.0 is scheduled to be released in September of 2009, coinciding with the release of GNOME 2.28. According to Billeter, the project is on track to make the 1.0 deadline, which will mark the start of a long stable release cycle during which application developers can count on language stability. The bindings to GNOME libraries are maintained separately, Billeter said, and are added to and enhanced on an as-needed basis, so they are not subject to the same schedule.
The project offers a tutorial and sample code for those new to Vala; some familiarity with GObject is expected. Benchmarks between Vala and C show no significant execution speed losses (in some cases, Vala even beats plain C).
The project maintains a list
of applications developed using Vala, in whole or in part, including GNOME
panel applets and full-fledged applications. The webcam utility Cheese is currently
maintaining a Vala branch in addition to its main trunk, just to road test
the viability of the language. Billeter noted that although people
generally think of using Vala only when starting a new project, it is
possible to incorporate it into an existing C code base, too. "Among
our users are both, people writing C that now want to move to something
higher level and also people that just start programming in the GNOME
environment,
" he said.
Clojure
While Vala is a language designed around a particular object system, targeting a particular desktop environment, Clojure could not be more different. It is a dialect of the functional-flavored programming language Lisp, implemented on the Java platform. That makes it cross-platform; Clojure applications are compiled to Java bytecode, so they can run on any platform with a well-supported JVM.
Creator Rich Hickey has explained that building on top of
the JVM grants Clojure automatic platform stability from a broad user and
developer community, but that itself was not the goal of creating the
language. Hickey's primary interest was concurrency — he wanted the
ability to write multi-threaded applications, but increasingly found the
mutable, stateful paradigm of object oriented programming to be part of the
problem. "Discovering Common Lisp after over a decade of C++, I said
to myself — 'What have I been doing with my life?', and resolved to
at some point code in Lisp. Several years of trying to make that practical,
with 'bridges' like jFli, Foil etc, made it clear that bridges weren't
going to be sufficient for the commercial work I was doing.
"
Hickey became less enamored of object oriented programming and started adopting a functional-programming style in his work, which he found to make the code more robust and easier for him and for his coworkers to understand. Eventually, maintaining that style in other languages like C# became more trouble than it was worth:
Clojure does provide persistent data structures, although it does considerably more. For those unfamiliar, functional programming (the style from which Lisp and Clojure originate) places a greater emphasis on functions as first-class objects, meaning that functions can be placed into data structures, passed as arguments to other functions, evaluated in comparisons, even returned as the return value of another function. Moreover, functions do not have "side effects" — the ability to modify program state or data. This paradigm focuses on computation in the mathematical sense, rather than procedural algorithms, and is a completely different approach to programming.
As a language, Clojure is a Lisp-1, part of the same family of Lisp variants as Scheme, notable for sharing a single namespace between functions and variables. Clojure differs from Scheme and other Lisp dialects in several respects documented at the Clojure web site. For application developers, the most significant distinction is that Clojure defaults to making all data structures immutable. To maintain program state, developers must use one of four special mutable structures that are explicitly designed to be shared between threads: refs, vars, atoms, and agents. Clojure uses software transactional memory (STM) to coordinate changing these mutable structures while keeping them in a consistent state, much like a transactional database. This model makes it considerably simpler to write thread-safe code than it is in object oriented languages. No locks are required, therefore there are no deadlocks or race conditions.
Like other Lisp implementations, Clojure is interpreted through a console-like read-eval-print-loop (REPL). The user launches the REPL from a .jar file and is presented with the REPL command prompt, from which he or she can load Clojure programs or directly write and execute functions and macros. The code is compiled on-the-fly to Java bytecode, which is then in turn executed by the JVM. The REPL environment is much like an interactive IDE and debugger all rolled into one, but for distribution purposes, Clojure code can be compiled ahead of time into ordinary Java applications. Because it is hosted by the JVM, Clojure can automatically make use of its features, including the type system, thread implementation, and garbage collector, rather than having to re-implement each of them. Clojure code can also call Java libraries, opening up a wealth of classes and interfaces to Clojure programmers.
Clojure 1.0 was released on May 4, 2009. There are several good resources online for learning about the language and for getting started, although a general introduction to Lisp is probably warranted for those with no experience in functional programming. Though there are not large-scale projects using Clojure, an active community is growing around it, including several local users' groups. The Clojure site offers documentation of the language syntax and examples (including example code), there is a very active Google Groups discussion forum, and Mark Volkmann's Clojure page at Object Computing tracks articles, slides, and wikibooks about Clojure.
Two-way interoperability
Vala and Clojure seem to have little if anything in common; one is object oriented and the other functional, one aimed at a specific desktop system and the other intentionally cross-platform. They are kindred spirits in one sense, however — they seek to build a more modern, robust language implementation on top of an existing, established platform. Vala's goal is to let C programmers more easily take advantage of the power of GObject and GNOME, and Clojure's is to let developers easily write concurrent applications on top of the stability of the JVM.
What is equally important is that both projects maintain bi-directional compatibility with their underlying languages and platforms. A Vala program can use any C library, and a C program can use any library written in Vala. Likewise, Clojure code can be compiled to Java, and Clojure applications can use any Java class or interface. Such interoperability will likely increase adoption of both of these languages, and it is a welcome sight in any project.
| Index entries for this article | |
|---|---|
| GuestArticles | Willis, Nathan |
Posted Jun 4, 2009 0:57 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Careful. It's a nice feature that users who don't have Vala can build a program from the C output from the Vala compiler. But one of the functions of source packages is license compliance, and it's important to remember that for purposes of GPLv2 or GPLv3, the source code is defined as the preferred form for modification, thus the Vala code is the source and the C code produced by the Vala compiler is not. Vala source must be made available for license compliance.
Posted Jun 4, 2009 11:03 UTC (Thu)
by njh (subscriber, #4425)
[Link]
Someone who wants to exercise "freedom 1" can do so, but will need to get a Vala development environment (much as someone who wants to do non-trival hacking on a project that includes a YACC parser will need Bison installed, but if they just want to build the program unmodified then they only need a C compiler).
Posted Jun 4, 2009 1:05 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (3 responses)
Ah, careful, you'll get a lot of Lispers' backs up with that one. Modern Lisps like Common Lisp and Scheme are not "interpreted". They are interactive, but most of them include compilers; the Common Lisp standard requires a minimal compiler, in fact, and many CL implementations don't have interpreters at all, instead compiling code as it's read in (to bytecode or machine code, depending).
Posted Jun 4, 2009 9:50 UTC (Thu)
by wingo (guest, #26929)
[Link]
Posted Jun 8, 2009 14:24 UTC (Mon)
by dwheeler (guest, #1216)
[Link] (1 responses)
Quite true. Many Lisp-based implementations include compilers, and many can generate very nice code (especially if given some type hints).
Some people are put off by Lisp's syntax ((((((lots of parens, no built-in infix)))))). If you're one of them, you might want to check out this page on making Lisps readable, in particular, sweet expressions.
Posted Jun 8, 2009 15:30 UTC (Mon)
by flewellyn (subscriber, #5047)
[Link]
Granted, the parens would be hard to keep track of without a good editor like Emacs, but I find the same to be true of other languages, be they braces-and-semicolon languages like C\C++\Java\PHP\Javascript\whatever, or whitespace-significant like Python. A good editor is essential no matter what.
Posted Jun 4, 2009 3:18 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (4 responses)
Posted Jun 4, 2009 6:05 UTC (Thu)
by tnoo (subscriber, #20427)
[Link] (3 responses)
Posted Jun 4, 2009 9:03 UTC (Thu)
by rwmj (subscriber, #5474)
[Link]
Posted Jun 4, 2009 11:58 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted Jun 4, 2009 12:45 UTC (Thu)
by tnoo (subscriber, #20427)
[Link]
Posted Jun 4, 2009 4:06 UTC (Thu)
by wahern (subscriber, #37304)
[Link] (15 responses)
Every existing STM library actually uses locks internally. Period. Please, stop the cargo cult hyperbole. The only real STM implementations are on paper, or maybe in a lab w/ a custom ASIC.
Posted Jun 4, 2009 5:18 UTC (Thu)
by jamesh (guest, #1159)
[Link]
The language's home page seems to be saying that STM is the concurrency model provided to programs written in the language (and that those semantics are limited to a single type of variable).
I am sure you are correct that it is implemented via locks internally -- it'd use the primitives provided by the JVM.
Posted Jun 4, 2009 9:44 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
For those who want to be accurate about it, STM moves responsibility for locking from the application developer to the STM implementor; the contract is that STM applications cannot deadlock, and as a quality of implementation issue, should not livelock.
As with many things in programming, the hope is to trade off the possibility of more performance (given a high enough standard of programmer), for reliability now.
Posted Jun 4, 2009 13:15 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
Posted Jun 4, 2009 18:37 UTC (Thu)
by wahern (subscriber, #37304)
[Link] (1 responses)
The Rock CPU ops would seem to mostly obviate the need for the dance.
Posted Jun 11, 2009 14:10 UTC (Thu)
by tvld (guest, #59052)
[Link]
Posted Jun 4, 2009 14:38 UTC (Thu)
by mitchskin (subscriber, #32405)
[Link] (3 responses)
Posted Jun 4, 2009 17:51 UTC (Thu)
by wahern (subscriber, #37304)
[Link] (2 responses)
"Software Transactional Memory", Nir Shavit and Dan Toutiou, 1997.
The confusion is part of what I'm raging about ;) You can't simply say, "well, by 'software' I mean whatever I want it to mean, and not what I'm implying".
Fact is, real STM does not exist. It doesn't exist in the JVM, it doesn't exist anywhere in production (notwithstanding the Rock CPU mention). It can only exist w/ a universal primitive like LL/SC, as proven by, I believe, Herlihy.
Everything else can deadlock, and can livelock (if you're providing STM semantics).
Now, as pointed out elsethread, yes, STM can provide conceptual amelioration regarding the semantics of a language. But when that new language is running on your desktop, there is no way to "fake" it.
Existing STM is analagous to Perl5/6's "quantum" operators. Conceptually useful, but it's not literally doing it.
But don't take my word for it. Here's a small list of relevant material. These are the papers I still have in my research directory:
"Software Transactional Memory", Shavit and Toutiou, 1997.
"A Methodology for Implementing Highly Concurrent Data Objects", Herlihy, 1993.
"A Methodology for Implementing Highly Concurrent Data Structures", Herlihy, 1990.
"A Practical Multi-Word Compare-and-Swap Operation", Harris, Fraser, Pratt, 2002.
"Impossibility and Universality Results for Wait-Free Synchronization", Herlihy, 1988.
"Practical Lock-Free and Wait-Free LL:SC:VL Implementations Using 64-bit CAS", Michael, 2004.
"Wait-Free Synchronization", Herlihy, 1991.
Posted Jun 4, 2009 20:08 UTC (Thu)
by Frej (guest, #4165)
[Link]
But it's not the only point of STM (today). It's about safety and ease of concurrent programming on shared memory architectures.
Secondly, you missed the paper that inspired Software TM:
Note that transactional hardware as an idea goes further back. But the above paper is pure hardware. Shavit and Toutiou later introduced Software Transactional Memory in the paper you posted.
So it is correct to distinguish between Transactional Memory and Software (assisted) Transactional Memory. Also, it does not make it pen and paper because the implementation uses locks. So surely STM exists, there are many implementations - The best are compiler/language assisted.
Posted Jun 11, 2009 14:06 UTC (Thu)
by tvld (guest, #59052)
[Link]
Assuming that your memory transactions don't block by waiting for external events to happen, no sane (S)TM will deadlock. Some might live-lock, but that is just a question of contention management, and not a principal limitation (remember that CAS is universal...).
Please actually do read the relevant literature.
Posted Jun 4, 2009 18:01 UTC (Thu)
by ekmett (guest, #58940)
[Link] (4 responses)
To implement a fully lock-free STM you use an atomic n-CAS. You are correct that LL/SC or DCAS isn't available on a modern CPU directly. However, you CAN build an n-CAS out of that very same x86 cmpxchg16b-style CAS operation. The derivation isn't very straight forward, so I'm not surprised that you didn't come up with it by yourself, but a construction exists. You wind up comparing and swapping the values of n 'slots' atomically, rather than swapping n machine integers directly.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1...
Once you have that, the derivation is straightforward.
The reason almost all transactional memory implementations fall back on ordered locks is because in practice the n-CAS STM is slower than the lock-based STM, not because no such construction exists.
<end lock-free STM cargo cult hyperbole>
Posted Jun 5, 2009 17:29 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (3 responses)
There are other DCAS algorithms, too, including (IIRC) one which is probabilistic (but strong). One problem I encountered is that early Opterons don't implement a 128-bit CAS.
Also, my particular task was implementing POSIX signals for pthreads-win32, which ruled out dynamic allocation (requiring locking) of context structures--required by many (all?) of these CAS algorithms.
Posted Jun 6, 2009 1:34 UTC (Sat)
by ekmett (guest, #58940)
[Link] (2 responses)
But even so thats a far cry from no implementation being possible. ;)
Posted Jun 8, 2009 19:52 UTC (Mon)
by wahern (subscriber, #37304)
[Link] (1 responses)
Should I just tell pthread-win32 users, "POSIX signals work without any trouble... just don't use more than N threads"?
That's not STM per the theory, is it? That's something very close to STM, but still requires workarounds and caveats. And w/ that attitude, Intel or AMD will never give us the hardware support that's needed.
Unless STM is simple and straightforward (which, even if the algorithm is complicated, it's _universal_, and so you won't have to roll your own everytime), then people will still mostly just _talk_ about STM rather than actually _using_ real STM, w/ the concomitant _realized_ benefits.
Posted Jun 11, 2009 12:33 UTC (Thu)
by ekmett (guest, #58940)
[Link]
Posted Jun 11, 2009 8:24 UTC (Thu)
by ketilmalde (guest, #18719)
[Link]
Really? I think there's a lot of talk about how STM is bollocks. While I haven't read the literature (as) extensively (as you seem to have), I've yet to see any rationale for this. More specific pointers than just a ream of research paper titles would be great.
> This is because pure STM requires the LL/SC
I'm sorry, but isn't this SOFTWARE transactional memory we're talking about? What's stopping the run-time system from abstracting away the underlying hardware?
> Every existing STM library actually uses locks internally. Period.
While I've only made toy implementations using it, Haskell's STM library seems awfully real to me. I'm not aware of any locking, but I could be misunderstanding how it works, of course.
Further down, you go on to claim:
> Fact is, real STM does not exist.
and
> Everything else can deadlock, and can livelock
While I love unsubstianted claims as much as the next guy, your opinions would be more enlightening if you provide actual example code that demonstrates this.
Posted Jun 4, 2009 9:05 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (7 responses)
It could have been a great step forward: type inference, non-intrusive static typing, ideas from functional languages, strong emphasis on safe programming practices ... All things which are needed by the free software community.
Instead we got a warmed-over C# clone with a syntax more verbose than
Java, and none of the innovations in language design which have happened in the past decades. Rich.
Posted Jun 4, 2009 13:30 UTC (Thu)
by walters (subscriber, #7396)
[Link] (6 responses)
Not clear what you mean by "safe programming"? Memory safety/garbage collection? In that case true, but it was a design goal of Vala to be independent of higher level runtimes and thus usable for lower level libraries in the stack.
Posted Jun 4, 2009 13:54 UTC (Thu)
by rwmj (subscriber, #5474)
[Link] (4 responses)
GUI toolkits can be designed on pure functional principles, although that wasn't what I was advocating. Look up Functional Reactive Programming. There are various toolkits for Haskell implementing these techniques.
Safety is always a good thing to build into modern languages, not just because no one wants their programs to crash so much, but because in some cases it really matters - errors and inaccuracies in GUI programs can have all sorts of effects from wasted time right up to death. Languages should be designed to reduce programmer mistakes. Garbage collection is one of many techniques in this area. Others include: design contracts, modularity, strong typing, phantom types, test-driven development.
Unfortunately all of this research seems to have passed over the heads of the developers of Vala.
Posted Jun 4, 2009 14:11 UTC (Thu)
by walters (subscriber, #7396)
[Link] (3 responses)
You missed by point that garbage collection would have been incompatible with a key Vala design goal. It didn't "pass over their head".
We can't use GC in the lower level components of the GNOME stack because then if you wanted to use a higher level language (like OCaml!) on them, you'd have two different garbage collectors in the same process which is a recipe for disaster.
Vala definitely has modularity and strong typing. I'd argue test-driven development is not a language feature but a cultural feature. I'm not familiar with phantom types.
Anyways, you seem to be essentially saying that because Vala isn't OCaml it must be broken, when there are actual engineering tradeoffs that you're not recognizing.
Posted Jun 4, 2009 14:13 UTC (Thu)
by rwmj (subscriber, #5474)
[Link]
Posted Jun 4, 2009 19:28 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Then why it's added to C#, C++ (gcc 4.4 at least does have it), etc? Are
you sure developers do it because they all are mad? Yup. Basically you are using type inference - just implemented
not in compiler as sane people are doing but in editor. And it produces
tons of useless clutter because it's implemented in wrong place. Why is it a disaster? You can combine compiled Java code (GCJ) and
Scheme code (Guile) in a single process - and everything "just works".
Sure, it's not exactly super-fast (you are scanning some small regions of
memory twice), but no other problems are shown... Nope. If you want to see the language designed around existing
OO-system, but which is done right - take look on Groovy. It's not perfect
(no
language is perfect) but it adds a lot of usefull features to Java while
reusing the same JVM. Sure, JVM does have richer set of features if
you compare it with GLib/GObject, but still the Vala is pretty pathetic
language.
Posted Jun 5, 2009 18:53 UTC (Fri)
by amaranth (subscriber, #57456)
[Link]
var reader = new Reader ();
Posted Jun 4, 2009 14:01 UTC (Thu)
by alankila (guest, #47141)
[Link]
With a C# keyword like "var" you can make the type information implicit, which makes it easier to write and change the code. Plus there's just something about:
Reader reader = new Reader()
collapsing to:
var reader = new Reader()
that makes the code much more readable to me. It's removing the type information that looks and feels like noise to me.
Then again, when there's a typo somewhere and the compiler can't figure out what the implicit type stands for, the errors that result are almost incomprehensible. I'm hoping Mono people can fix the parser to abort earlier instead of filling "var" with "object" and proceeding until it crashes and burns 5 lines later with missing methods and wrong types for calls etc. Usually the first thing to debug problems like this is to add some type information back so you'll pínpoint the line where it goes wrong.
Posted Jun 4, 2009 13:23 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Famouos last words :-) Erlang doesn't have mutable variables, so there's no need to use locks, still it's fairly easy to introduce deadlocks and race conditions as long as there's message passing between threads.
Posted Jun 6, 2009 14:03 UTC (Sat)
by aanno (guest, #6082)
[Link]
Posted Jun 11, 2009 14:17 UTC (Thu)
by tvld (guest, #59052)
[Link] (1 responses)
Posted Jun 17, 2009 6:53 UTC (Wed)
by j1m+5n0w (guest, #20285)
[Link]
A look at two new languages: Vala and Clojure
The resulting C compiles normally with gcc, plus it can be distributed as source packages fully usable on platforms that do not have Vala installed.
A look at two new languages: Vala and Clojure
A look at two new languages: Vala and Clojure
A look at two new languages: Vala and Clojure
Clojure - many Lisp implementations compiled, syntax alternatives
Clojure - many Lisp implementations compiled, syntax alternatives
Clojure and JVM languages
running on the JVM. That space seems to be getting a lot of activity these
days, most notably (besides Clojure) with Scala, Groovy, and JRuby. The
dynamic-language support planned for the next major JRE release will
likely accelerate this trend.
Clojure and JVM languages
And OCaml ...
Clojure and JVM languages
Clojure and JVM languages
somewhat slow development. The languages I mentioned are either JVM-only
languages or are current and competitive with the C equivalent.
well, version 2.5 is under
way, which is not bad considering that language changes small between
versions.
Clojure and JVM languages
Transactional Memory
Transactional Memory
Transactional Memory
Transactional Memory
Transactional Memory
Transactional Memory
Transactional Memory
The only real STM implementations are on paper, or maybe in a lab w/ a custom ASIC.
It sounds like you're thinking about hardware transactional memory. Software transactional memory (STM) may indeed be implemented using locks, but it does provide an interface that means client code can avoid using locks directly. You're right that there still may be locking somewhere, but that can still be a win since it isolates locking to one widely shared piece of code.
Transactional Memory
Transactional Memory
Transactional Memory: Architectural Support for Lock-Free Data Structures
Herlihy & Moss (1993)
Transactional Memory
Therefore, you can build nonblocking STMs, and people actually do (see, for example, the paper describing DSTM (one of the first STMs)).
Transactional Memory
STM _can_ remove locking on modern hardware, but you're using the wrong primitives.
Transactional Memory
Transactional Memory
rather than raw pointers, it is just less elegant.
Transactional Memory
Transactional Memory
Transactional Memory
> Please, stop the cargo cult hyperbole. The only real STM implementations
> are on paper, or maybe in a lab w/ a custom ASIC.
Vala is a bit of a lost opportunity.A look at two new languages: Vala and Clojure
A look at two new languages: Vala and Clojure
A look at two new languages: Vala and Clojure
A look at two new languages: Vala and Clojure
Type inference is possible with OO languages. Ironically recent versions of C# have a rather pathetic form of type inference.
Sure (and what is ironic about it?), but what I am claiming it that it's not overly useful in a heavily imperative/OO context, given that C++/Java/C# programmers have gone many years without it. Eclipse does a good enough job at filling out generics right now for me.
Unfortunately all of this research seems to have passed over the heads of the developers of Vala.
design contracts, modularity, strong typing, phantom types, test-driven development.
You really should read this essay!
A look at two new languages: Vala and Clojure
Are you sure all the language developers are mad?
Sure (and what is ironic about it?), but what I am claiming it
that it's not overly useful in a heavily imperative/OO context, given that
C++/Java/C# programmers have gone many years without it.
Eclipse does a good enough job at filling out generics right
now for me.
We can't use GC in the lower level components of the GNOME
stack because then if you wanted to use a higher level language (like
OCaml!) on them, you'd have two different garbage collectors in the same
process which is a recipe for disaster.
Anyways, you seem to be essentially saying that because Vala
isn't OCaml it must be broken, when there are actual engineering tradeoffs
that you're not recognizing.
Are you sure all the language developers are mad?
A look at two new languages: Vala and Clojure
No locks are required, therefore there are no deadlocks or race conditions.
A look at two new languages: Vala and Clojure
Just to be complete, there is another functional language that compiles to Java bytecode called CAL. CAL is inspired by Haskell and hence strongly typed.
A look at two new languages: Vala and Clojure
Transactional Memory does not require functional languages
Transactional Memory does not require functional languages