Slashdot Mirror

Oh, and I disagree that Axis is any good at all

I agree that Axis sucks. XFire is another nice java alternative.

Well, it's a case of which "unsafe" things you allow, I suppose. I don't personally think that direct memory manipulation through pointers and the like helps you if you're using a rich language, and you don't want to actually write something which manipulates memory as its primary function (like a garbage collector or whatever). Dynamic typing is a different matter though, particularly for Rapid Application Development. Another fun-looking language for the CLI is Boo, which is "Python-inspired", with (optional) stronger typing and more influence from CLI languages, rather than an actual dialect of Python, as IronPython is.

In TFA there is a link to Grails http://grails.org/ , which is slightly different than jumping on the Java bandwagon. The Grails base is Groovy http://groovy.codehaus.org/, which is a promising (still little immature) dynamic language. I think Java developers better take a look on the changing world, otherwise they will end up as their COBOL ancestors. Similarity: how many big-iron J2EE servers were 3 years ago, and how many were "upgraded" to Dells running whatever-app on Linux.

I am wondering if Groovy is not dead. For example see this:
http://jira.codehaus.org/browse/GROOVY-1194

This bug is pretty serious and it was filed 4 months ago. No reaction so far.

The paranoid should not be using a public repository. Set up your own Maven proxy:

http://maven-proxy.codehaus.org/

Then, tar a local repository with known good md5's and commit that with your project.

So when are they going to get round to addressing the issues described in this document? http://docs.codehaus.org/display/MAVEN/Repository+ -+Security+by+nat+pryce

I like the different languages the CLR can run, but it doesn't help the problem the OP describes.

When you have a dozen, or dozens, of developers having to go into, understand and modify each other's code, the .NET language agnostic VM won't help you. What if the one guy writing in Boo up and quits one day. The guys all writing in C#, C++, VB.NET, whatever language(s) you've allowed, have to take it over. That costs time and money. Up front, it also indicates how much of a risk allowing random languages can be.

I think I disagree with most of the other posters here, it is a good idea to standardize on a language. While good programmers can jump into just about any language and understand, it takes years to be an expert (C++ anyone?). That said, it is sometimes necessary to introduce multiple languages. Many Java and .NET developers still bridge the gap to C or C++ very often. Even so, I just don't agree that introducing a language like Python or Ruby into that environment necessarily helps productivity. It might help the one guy who loves to use that language, but overall it just hurts the project.

Um. After all this time, Groovy still doesn't even have a remotely complete formal specification. Groovy is a classic example of an ad-hoc language.

Also at PDC, there was a presentation about new features being added to the next version of the .Net runtime, to better support dynamic languages. And back to C#, the new 2.0 supports closures, and 3.0 will have type inferencing. Plus there are rumors of some sort of macro facility coming.

If you want a language with Python like Beauty, that is statically typed, uses the mono or .NET framework and is as fast as Java then you should check out Boo:

http://boo.codehaus.org/

There doesn't have to be a trade off.

Static typing allows you to catch 'compile-time' errors. The earlier you catch errors in the development cycle, the quicker they are to fix. Also static typed languages generally perform better.

Where as Dynamic languages like Ruby have the benefits of being quicker to develop as you can can skip the 'compile step' and lets you do more with less code.

Although there exists languages like Boo (http://boo.codehaus.org/ that lets you have both.

Advanced features like Type Inferencing lets the compiler 'infer the type' so you don't have to write it each time.

While built-in support for lists, hashtables, regular expressions, Extension methods, closures and callables (Functions as first class citizens) allows you to write code as terse and easy as Ruby, Javascript and PHP.

You can run in interactive mode on the fly 'without needing to compile', yet also be able to compile to byte code which gives you the performance benefits of C# and Java.

Boo also has coding conventions that are actually useful as it allows you to type code that you mean. e.g.

#Example in Boo
class Example:
    _privateIntList = [1,2]
    publicStringField = "String"

    [Property(Name)]
    _privateString as string

    def ToString():
        return "Hello, ${_privateString}!"

examples = [Example(Name:"Foo"),Example(Name:"Bar")]
examples.Add(Example(Name:"Joe"))

for example in examples:
        print example

#Equivalent example in Java
import java.util.*;

class Example
{
    private List _privateIntList;
    public String publicStringField = "String"
    private String _privateString;

    public Example()
    {
        _privateIntList = new ArrayList();
        _privateIntList.Add(1);
        _privateIntList.Add(2);
    }
    public String getName()
    {
        return _privateString;
    }
    public String setName(name)
    {
        _privateString = name;
    }
    public toString()
    {
        return "Hello, " + name + "!";
    }
    public static void Main()
    {
        List examples = new ArrayList;
        Example fooExample = new Example();
        fooExample.setName("Foo");
        Example barExample = new Example();
        barExample.setName("Bar");
        Example joeExample = new Example();
        joeExample.setName("Joe");
        examples.Add(fooExample);
        examples.Add(barExample);
        examples.Add(joeExample);
        for (Example example : examples)
        {
            System.out.println(example);
        }
    }
}

You shouldn't need a dynamic scripting language to be productive. If you want something with the productivity and brevity of Ruby with performance >= Java, you should check out Boo (http://boo.codehaus.org/).

It can run on mono/.NET which gives you access to the .NET Framework, has Python inspired syntax (wiithout the annoying quirks), and advanced language features not even found in Java like: properties, events, closures, extensions, macros, partial classes, etc.

It can run in interactive mode (without needing a compile) or compiles down to CIL giving it the same performance as C#.

I was suprised when I got my ASP.NET application running without changes on my Linux Web Server. It turns out that most of .NET is implemented except for omissions like 'Enterprise Services' (Active Directory) in its place they have an LDAP namespace which you can use to talk to any LDAP-compatible directory (i.e. Novell Directory, Open LDAP, etc)

But as a webdeveloper using ASP.NET you can consider it 'cross-platform', ASP.NET 1.1 is fully compliant and most of ASP.NET 2.0 is though you have to use the 'gmcs' compiler to currently use C# 2.0 features.

Also being a Java developer, using XSP to develop with is unfamiliary productive, it boots in a fraction of a second - a lot less than the 8 seconds for my basic tomcat installation.

mod_mono has benefits as ASP.NET can be run as a first-class citizen (similar to perl,php,etc) on apache without needing to open any other ports and without needing to run mod_proxy/mod_jk services.

There is a lot to like about mono. C# is a far superior language than Java, I can't see how people can think otherwise. Typed Exceptions is the only 'feature' missing (read: annoying code-bloat) and that is by design. C# features include: Properties, Indexers, Delegates/Events, Partial classes, ref/out params, Operator Overloading.

Although one of my favourite things about mono is that it can run Boo (http://boo.codehaus.org/) on Linux. It is an advanced agile, statically-typed agile language that has Python's power and brevity with C# performance. It can also run in interactive mode which efectively gives you a scripting language productivity with a compliled language performance - the best of both worlds.

Personally coming from a Java web-developer perspective I'm not a fan of ASP.NET webforms for all situations, (Its really productive for Intranet applications) but for my Internet applications I still prefer to generate XHTML/CSS so I need servlet style control, its good to know that with .ashx files and the IHttpHandler interface you have them out of the box.

Also Mono is 'Open Source' (In contrast to other popular platforms :), as a result it is installed by default in Fedora.

println """
<html>
  <head><title>All your Property Files!</title></head>
  <body>
"""
new java.io.File(context.getRealPath("/WEB-INF")).each FileRecurse{ file ->
  if (file.name =~ /.properties$/) {
    out.println "<table border='1'><caption>${file.name}</caption>"
    file.eachLine { line ->
      def property = line.split('=')
      if (property.length == 2)
        out.println "<tr><td>${property[0]}</td><td>${property[1]}</td ></tr>"
    }
    out.println "</table>"
  }
}
println """
  </body>
</html>
"""

I think C++ wants to be a low level language that can also do high level constructs.

And I do think this is a great goal, a goal that not many languages are able to do well.
Actually I don't know of any other language that allows you to type raw assembler and at the same time use higher order functions like boost::bind (http://www.boost.org/libs/bind/bind.html).
(Please not that C# and D delegates don't have all the features of bind, that is binding any argument to a precomputed value, not just the first argument).

But while the low level programming in C++ is good, writing high level functionnality is still very complicated. Just have a look at the code at the previously mentionned boos::bind and you'll probably run away (http://cvs.sourceforge.net/viewcvs.py/boost/boost /boost/bind/mem_fn_template.hpp?rev=1.7&view=auto) .

After reading the article, I understand that they are willing to fix this issue, at least partially.

But there are many other issues that preclude it to be really "comfortable" to use as a high level language :

Some of them are old issues, already solved many years ago by a lot of languages like parent post said (introspection (compile-time and run-time), modules, lambdas...).

Some other issues are old but require some carefull thinking to integrate well with C++: multi-methods, garbage collection, mixing functional and imperative programming...

An finaly there are new needs arising like compile-time code generation, aspect-oriented programming, multi-process programming, interfaces (as in the Heron language or the boost interface library, not Java interfaces)...

Of all these features, very few will be added in C++0x.

Other C++-like languages do offer these features or a subset of them.
Here is a short list for reference :
D : http://www.digitalmars.com/d/index.html
Heron : http://www.heron-language.com/
Boo : http://boo.codehaus.org/Language+Features
Nice : http://nice.sourceforge.net/
etc.

But to my knowledge none of them has fully succedeed in offering both a good low and a good high level programming, while keeping the zero-overhead principle of C++ (that is: if you don't use a feature of the language, you don't pay for it).

Seeing this situation, I'm afraid we have only 2 options :
1- split programs into 2 parts: high level and low level, and use 2 different languages for these parts.
2- create a new language

Actually, this is already happening:
I see more and more programmers using high level languages like Python and doing some system or high performance routines in C (with Pyrex for example) and then glue them together.

The languages I mentionned before (D, Heron, etc) are an attempt at creating a successor of C++ but IMHO they are not mature enough and/or feature complete.

So... I forsee option 1 will become more and more comomon for years to come, until we hit option 2, because I think C++ will not be fixed.

Absolutely. All I get concerned about is the idea that because some projects are far faster with Ruby alone or with Rails, then this is a general advantage that this sort of development technique will have over Java in all circumstances for all scales of project.

Ah, well, we're in agreement there! I'm a firm believer in using the right tool for the right job, and as you say, sometimes Ruby isn't the right tool for the job. Java does have some neat libraries and APIs, and alternative languages for the JVM like Nice, Groovy or Scala, can make one's life quite a bit simpler. You also get the performance advantage, which is always nice.

Where I am it is time to say Merry Christmas!

Here too. Merry Christmas! :)

"Python cannot really compete with Java or C# on big server systems. And I don't see how to fix it, either, without breaking the beauty of the language."

See boo: http://boo.codehaus.org/

It is just as fast as C#, with a python-like syntax.

Python is a dynamically typed language.

This was the answer I was expecting, which is why I specifically stated "as compared to Ruby". An interesting language for this is Boo, a Python-like .NET language which has a static typesystem.

Another issue that I have personally encountered concerns reference counts. Python extension modules are written in C.

To be completely fair, just writing in C presents this. However, just because extension modules can be written in C, does not mean they have to be. It is quite dangerous, but most langauges (Java, C#, I assume Ruby, Haskell through GHC, etc.) allow linking into unsafe code in some way or another. It just seems a pity that the reference implementation of Python is written so largely in C (although some would argue this is a matter of practicality). I like the look of the PyPy project, which is implementing Python in Python, in order to get around these problems though.

Starting a Python program may take a few seconds at 100% CPU, because the interpreter needs to process all imported modules. This also disqualifies it for some purposes.

...but not many, to be fair — JIT compilation of any kind carries similar problems though. I believe it may be more pronounced in Python, but I'm really not sure.

Dynamically typed languages like Python can be really useful for scripting and prototyping, but I wouldn't rely on them for mission-critical applications. You can quickly create a simple program but it is hard to be sure that it is really stable.

I essentially agree with this — in particular, it does always feel unsafe to me to program in such a language. There is a great many automated checks one can do without a typechecker though, which can greatly improve the reliability of a system. Another point is that with the sort of applications that Python and Ruby are used for, reliability is not always priority number one, particularly when the systems are built on top of a proven framework.

Granted, some of the frameworks, like Stackless and Rails, may not run on these tools, YET ... but there's really no reason to start totally from scratch and throw out a nice VM and a nice set of libraries...

In practice, strong typing and the lack of Ruby-style dynamism allows compilers and runtimes to make optimizations they otherwise couldn't. Those matter, a lot, try looking at the memory usage or execution speed of your average Ruby program sometime! Worse, it's an unfixable problem, at least without modifying the language itself quite heavily.

I think the way we're going to go with language design, as an industry, is more like Boo - a language which on the surface looks like Python and has many of the clarity and programmer efficiency features that make Python so much fun to use, but under the hood is actually a traditional strong/static typed language. In Boo, type inference is used to let you drop many of the redundant type declarations that normally clutter up Java/C#/C++ style code, and a smart compiler plugin system is used to let you add new features to the language easily. This is traded off against the ability to do things like add/remove methods at runtime which are hard to implement in a time/space efficient manner.

To be fair, although Python is quicker to develop, it's harder to verify due to having a less rigorous type system. I know this is part of the reason it is not used at my company. I quite like the approach taken by Boo in these terms, actually.

Or Boo.

Don't kill me.

The JVM and the J2SE class libraries are the most important contributions made by Sun under the Java technology umbrella. The Java language itself is irrelevant. Many people dislike the language syntax, and they have the right to do so. Syntax is a matter of taste - everybody should be able to program using the language they like the most (for the task at hand). But portability, interoperability, security, and other core features of the Java runtime are often underestimated.

People should stop fighting over language syntax and recognize that what we should be striving for is a feature-rich platform independent runtime, and that is what Java is in its essence. Groovy, Jython and JRuby are initiatives that recognize that.

There are definitely things that Java doesn't have that it's the weaker for. I miss closures and other features of dynamic languages constantly.

Me too. Check out Groovy.

to say this, but C# isn't the only language which runs on the Common Language Infrastructure, which is to say, .NET on Windows or Mono on Linux.

But still, you say, evil Microsoft owns the standard! Vendor lock-in, oh no!
Actually, it's an open standard maintained by ECMA. That's right, those same evil people who maintain things like the standard for javaScript.

This is by far the most hyped feature of C# but it's also present in Java. If you look at the large incompatibilities between Visual Basic and VB.NET you'll see that .NET is not really that language independent and that each language is really more of a "skined" version of C#.

As far as alternative languages go in Java there are many. Among the most popular are: JRuby
# interpreter written in 100% pure Java
# Most builtin Ruby classes provided
# Support for interacting with and defining java classes from within ruby
# Bean Scripting Framework (BSF) support
# Distributed under a tri-license (CPL/GPL/LGPL)

Jython (Python)
Jython is an implementation of the high-level, dynamic, object-oriented language Python written in 100% Pure Java, and seamlessly integrated with the Java platform. It thus allows you to run Python on any Java platform.

Groovy
Groovy is an agile dynamic language for the Java 2 Platform that has many of the features that people like so much in languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax.

There's a lot more smaller projects like JavaScript and Rhino, Jelly, BeanShell, Tcl/Java, Sleep, ObjectScript, Pnuts, Judoscript. Some people event think there are too many alternative languages for the Java Virtual Machine.

I don't know *anything* about those other products, but it strikes me that Postgresql could without too much effort have Java as a stored procedure language.

Indeed, someone has already started it http://plj.codehaus.org/

I'd actually say that it looks like it's taking a lot of Boo's features. The inferrence, the lambdas, there's only 2 features that Boo doesn't have, and they'll be taken care of within a month.

http://boo.codehaus.org/

The answer to your question is no. Java has clearly borrowed some things from C#, though C# itself heavily borrows from Java. The EJB 3.0 spec for example will make use of dependency injection. Take a look at Groovy which will be integrated into Java (javax.script in 6.0.)

Now it is true that as a more widely used (on the Enterprsie level) language, Java is going to move more slowly than C#. C# is newer and trying to take mindshare from Java, so it must move faster. Just having a great IDE is not enough.

As for the language, we used Python in Unity http://www.otee.dk/ for the initial preproduction of GooBall. It was soooo slow. After that we switched to Mono. CPU usage in the scripting logic went for >40% to app. 5%... If you like the Python syntax, you can always include boo http://boo.codehaus.org/ which mimics Python very closely, but uses type inference to get type safety automatically. On another note: the article states that Unreal does not use microthreads. That is not correct.

as a RAD it blows away even the best that .NET has to offer.

It is RAD and is a very cool language, however, one thing that Python does not have going for it is its execution speed. It's fine for small stuff, scripts and little apps, but anything larger and you're lost in a sea of interpreted code.

FYI, you can still code for Python and compile to .NET. Why? Native Windows UI widgets (Windows Forms), an extensible, powerful application framework, and SPEED! Python compiled to run on the .NET platform runs faster than Python 2.3. See http://ironpython.com/ And yes, it is cross-platform, IronPython is runnable on Mono.

Also, Microsoft made an interesting move recently: it hired the creator of IronPython and is now actively developing Python which runs on .NET and Mono. In fact, you can go to MSDN and download it right now.

Anyways, Python is a cool language. I'm helping out with a Python-derivative language called Boo, check it out here.

1. Kudos to the Groovy authors. They've even garnered James Gosling's attention. If you write Java code and consider yourself even a little bit of a forward thinker, look up Groovy. It's a very important JSR (JSR-241 specifically).

2. He talks about Javascript solely from the point of view of the browser. Yes, I agree that Javascript is predominently implemented in a browser, but it's reach can be felt everywhere. Javascript == ActionScript (Flash scripting language). Javascript == CFScript (ColdFusion scripting language). Javascript object notation == Python object notation.

But what about Javascript and Rhino's inclusion in Java 6? I've been using Rhino as a server side language for a while now because Struts is way too verbose for my taste. I just want a thin glue layer between the web interface and my java components. I'm sick and tired of endless xml configuration (that means you, too, EJB!). A Rhino script on the server (with embedded Request, Response, Application, and Session objects) is the perfect glue that does not need xml configuration. (See also Groovy's Groovlets for a thin glue layer).

3. Javascript has been called Lisp in C's clothing. Javascript (via Rhino) will be included in Java 6. I also read that Java 6 will allow access to the parse trees created by the javac compiler (same link as Java 6 above).

Java is now Lisp? Paul Graham writes about 9 features that made Lisp unique when it debuted in the 50s. Access to the parse trees is one of the most advanced features of Lisp. He argues that when a language has all 9 features (and Java today is at about #5), you've not created a new language but a dialect of Lisp.

I am a Very Big Fan of dynamic languages that can flex like a pretzel to fit my problem domain. Is Java evolving to be that pretzel?

Anyone who writes in Groovy, Python, ObjectScript, JavaScript, NetRexx, and many others. There's a scripting JSR as well. I don't think the original poster had this specifically in mind though.

As a long time J2EE developer, I hear ya. I did a lot of investigation and experimentation with RoR, for the very reasons you listed. I tried out some of the tutorials and was amazed at how fast it was to get something going and how little code/configuration there was to write. I think RoR is on to something, but is way,way off from being anything other than a great prototyping tool right now.

It uses a lot of assumptions and works best with MySQL. Once you start using it with a legacy database and start having to throw in things distributed transactions on dbs like Oracle, then it suddenly becomes a lot more painful. Throw in making it deal with a stored procedure or some complex CRUD-related logic, and suddenly you start wondering what the point was at all. If you can start from scratch on your schema, so that you can devise your schema so that all your CRUD is straightforward, and only have to deal with a single open source database, then it's great. In other words, it's great for prototyping.

I think other technologies (J2EE and .NET) will borrow for RoR though. Groovy will make it a lot easier to do something exactly equivalent to RoR inside a JVM. It won't be too hard for such a framework to make use of JTA as well as the many other technologies in J2EE (and the open source projects based on it.)

What makes this slightly interesting is the IBM connection:

Geir Magnusson Jr. is a lead in the proposed Har mony Project

Geir Magnusson Jr. is from Gluecode, which IBM has acquired.

If it weren't for that, I'd just say "yeah, whatever - it's just another JVM implementation."

Geir Magnusson Jr. is from Gluecode, which IBM has acquired.

What is IBM really trying to buy here? I always thought that when IBM wanted Java they'd just buy Sun.

The Codehaus hosts a couple decent .NET projects, although it does have a heavy java bias at present. Neo is an entity persistence framework for .NET, and Boo is a new language for the CLI supporting things like macros and closures.

The Codehaus hosts a couple decent .NET projects, although it does have a heavy java bias at present. Neo is an entity persistence framework for .NET, and Boo is a new language for the CLI supporting things like macros and closures.

The Codehaus hosts a couple decent .NET projects, although it does have a heavy java bias at present. Neo is an entity persistence framework for .NET, and Boo is a new language for the CLI supporting things like macros and closures.

The Codehaus hosts a couple decent .NET projects, although it does have a heavy java bias at present. Neo is an entity persistence framework for .NET, and Boo is a new language for the CLI supporting things like macros and closures.

Codehaus is a similar site with a lot of cool stuff.

Perhaps more seriously, third-party patches won't be considered until after the 1.0 release. Hugunin encourages people to be involved, but only in filing good bug reports and feature requests. And when doing this involves a .NET passport, and using the GotDotNet web forums rather than good old mailing lists, it's a bit of a disincentive.

Added to that, there's some uncertainty about the freeness of IronPython's license. While it looks free, it's got the same name, "Shared Source", as several Microsoft licenses that definitely are not free.

Groovy has been taking a lot of heat lately. Boo seems not to suffer from the management/community problems Groovy has. In fact, Boo is just plain more exciting; Groovy is just Ruby disguised in Java syntax, as far as I can tell, whereas Boo takes what's best about Ruby (heavy emphasis on closures/blocks), Python (indent-based scoping, first class functions), and C# (static typing, properties, annotations, "using", p/invoke, .NET native), and one-ups them with type inference. It really does provide the best of both static and dynamic typing; there is NO compromise here as far as I can tell.

As a bonus, the tool support is already very good. As with any self-respecting scripting language, it includes an interactive interpreter. (Boo scripts can be interpreted or compiled.) The Visual Studio .NET debugger already works with Boo, and if you write your Boo code in SharpDevelop (a free IDE for .NET platform) you can get code completion, syntax highlighting, code folding, etc. And since it's all statically typed, there is hope for IntelliJ-like refactoring tools, although I don't think any exist yet.

Bottom line, I think any Python, Ruby, or Groovy fan should take a long, hard look at Boo. You will find a whole lot to like.

Lately, I've become interested in Groovy, a JVM-based scripting language that combines concepts from Java (syntax, access to the class libraries) with concepts from Perl (dynamic typing, native syntax for collections and regular expressions). It would be interesting to see something similar for .NET.

Visual Basic and Java and Python and Oberon and Object Pascal and Boo and Nemerle and Component Pascal and Forth and Lisp and Smalltalk and Logo and Tachy.

Some of the packages are still in the larval stages, but they're out there, and more are on the horizon.

This is a good start, but there are a couple of ways to improve.

First, Java's serialization format is pretty opaque. That makes debugging, testing, and schema migration a pain in the ass. A better choice is XML via XStream. If you have a good object model, its output XML is pretty readable. And you can improve that by adding custom adapters for particular objects. And for the XML-is-too-verbose crowd, let me suggest putting a GZIPOutputStream in the chain.

You generally do have something like GameMap or MobileObjectsHashTable though.

This is a good approach in Perl, but in Java you can do better. When I see classes with names like that, it generally means the programmer is thinking too much about implementation and not enough about design. Instead of GameMap, it should be Game. Instead of passing in string keys and casting objects when you (hopefully) get the right ones out, take advantage of the language's static typing and put all that work inside of the Game object.

For more on this topic, read the excellent book Domain-Driven Design.

I thought that's what CodeHaus's ActiveMQ was for.

CodeHaus rocks, even if they are overly java biased for my tastes.

Two leading AOP projects, AspectJ and Aspectwerkz, just merged. Their technologies, developer skills, and user communities were complementary, and the resulting common platform will be developed quicker and be of better quality. The user community benefits from sharing and gets bigger, creating more shared benefits...

Competition is useful as incentive and to provide choice, but ultimately something wins because it's better. I think it better to win through mergers, which preserve the best of both companies, er, projects.

http://eclipse.org/aspectj
http://aspectwerkz.codehaus.org/

On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.

This is why I think Boo is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing to just resolve everything at runtime Python-style.

On the other hand, in that situation the compiler isn't working for you. It isn't working against you, either, but a bug found for you is a bug you don't have to track down.

This is why I think Boo is so damn nifty. It's statically typed, but will infer types if possible (unless the user decides to use the optional explicit typing), and also allows duck typing to just resolve everything at runtime Python-style.