[quote]Gosu is a general-purpose programming language built on top of the Java Virtual Machine (JVM). It is object-oriented, static typed, imperative, and 100% Java compatible (use/extend Java types, implement Java interfaces, compile to Java bytecode). It has type inference (very readable code yet static typing!), in-line functions that you can pass as objects (closures / lambda expressions / blocks), enhancements (inject methods + properties, even on Java types!), and simplified generics.
[/quote]
Going through this:
I’m not seeing a great deal of +ve here?
Kev
It’s nice to see more languages built for the JVM, however this one doesn’t look very special to me. Just Java with:
- lots of small changes ‘simply to be different’
- some features missing
- some type inference
Only one of those I’d be interested in and even then I really don’t like languages which try to offer both static and type inference. It feels a bit like a half hearted attempt to support all members of the audience. I mean why have type inference if you have static typing and why have static typing if you have type inference? If your going to support type inference then IMHO I feel it’s better to throw away the static typing and have it fully built into the language, like Haskell.
What I dislike the most is that there doesn’t seem to be any real USP. Closure, Scala and JRuby all have a unique purpose or direction that justifies their creation. The justification for this seems to be to use a couple of less key strokes then standard Java, which isn’t that big of a deal to me. If it was then I could just use Beanshell (something which also has a USP since it’s tiny and embeddable) or Scala. I just fail to see the point in this.
But I hate to be just negative. Writing just a half decent programming language is not trivial, so I fully respect the creator of this for his work.
What?
Reading through the changes, I can guess at the reasons they were made. What changes do you think are solely to be different?
What features are missing? It deviates from Java in some ways (eg, constructor syntax).
Strongly disagree. Read this:
http://www.cakoose.com/wiki/simple_type_inference
[quote]What I dislike the most is that there doesn’t seem to be any real USP.
[/quote]
What?
Can’t you guys just type the freaking words so I don’t have to guess what you mean? Using acronymfinder.com, I guess you mean Unique Selling Proposition.
Java is pretty good. A lot of my qualms with it are small. I think the ideal JVM language takes Java and fixes all the little minor issues to reduce verbosity and improve productivity. From reading a couple pages on Gosu, it sounds very nice! They even seem to have an Eclipse plugin:
http://gosu-lang.org/eclipse.shtml
I haven’t tried any of it yet, but it looks like it has a lot of promise.
There are a couple of serious red flags that I see here, based on a brief look through:
- Case insensitivity…just, why??!!!??
- “Gosu generics support array-style variance of different generic types. In Java, this is a compilation error, even though it is natural to assume it works.” Yipes. Yeah, it’s natural to assume that it works, until you take the example that they’re complaining about (and that apparently is allowed in their language) and actually do something with the result:
ArrayList<Object> mylist;
mylist = new ArrayList<String>(); //apparently they don't think this should be a syntax error...
File myFile = new File();
mylist.add(myFile);
-->
BOOM!!! We've just added a File to an ArrayList<String>, and congratulations, you've just completely destroyed the type-safety of your language, YAY! This is why Arrays Are Not To Be Trusted in Java, every time you use one you carry around the risk that someone will assign your nice pure MySpecialObject[] array to an Object[] reference and then try to assign a String to some index in it.
The unwashed masses have little need to know about covariance/contravariance, but when a language designer doesn’t understand why the concepts even exist, that makes me question whether they’re really qualified to be designing a language…this stuff is literally the entire reason generics are so messy in Java, why we need wildcards and the extends and super tags, and yes, it’s super nasty, but that’s the price you pay if you want type safety.
I’d even be fine with it if they indicated that they were consciously making this tradeoff, but that’s unclear.
- Reification is great, but a lot less so if native Java types are not reified. Wrap those suckers up, and hide the “native” ones if you want to do reification! Halfway solutions are nasty, there’s a reason that most other JVM languages wrap up even primitive types so that everything has the same semantics, and this is a similar issue! If you don’t fix these things, then you end up just inheriting most of the crap that made the original language imperfect.
Personally, I see a bunch of small improvements, but nothing that really sells this to me over Groovy, Scala, or Clojure (in rough order of “How far away from Java do I want to go?”).
I like case insensetivity in dynamic languages, as it invalidates lots of small typos you can hit at runtime. There is also no point in allowing people to have: foo, Foo and FOO.
I also love the way in VBA you can write in one case continuously and it will alter the code so it’s all cased correctly for you. It means I never have to use shift or caps lock.
Although your completely right, in practice I have never encountered this issue when writing real code. If I never encounter it in practice then I just don’t think this is a real issue.
My personal gripe with generics is that it only works in one direction. You can’t have two classes use each other as a generic parameter. I’d like to be able to do something like:
interface SpriteHolder<A extends Sprite<B extends SpriteHolder<A>>>
{
List< Sprite<B extends SpriteHolder<A>> > getSprites();
}
interface Sprite<W extends SpriteHolder<Sprite<W>>>
{
SpriteHolder<Sprite<W>> getParent();
}
I want Sprites to be able to know the full qualified type of their parent SpriteHolder, whilst allowing SpriteHolders to have the full type of Sprites they are holding. AFAIK you can’t do this; the only solution is to override the appropriate methods and use casts in your implementing classes (and then it only goes some of the way). This is also something that I’ve wanted to use (several times) in real code.
Personally, I don’t think Gosu is all that interesting. Just wanted to forward it over here.
Well, Scala is fairly fast. I wonder how Gosu compares. (I probably won’t use either though.)
On some benchmarks Scala even out performs Java, on it’s own JVM. That’s impressive!
I’d still like to see BASIC with Classes implemented atop the JVM 
Without case sensitivity or public/private/protected modifiers. And LWJGL built in 
Cas
Unless you use a simple for-loop (https://lampsvn.epfl.ch/trac/scala/ticket/1338 ). Must that good old for (int i=0;i<10;i++) really be deprecated?
And what strikes me most is that I’m afraid I’ll never fully grasp the scala type system - take a look at http://apocalisp.wordpress.com/2010/06/08/type-level-programming-in-scala/
Maybe then the Gosu approach to accept an inconsistent type system isn’t that bad as long as your team understands the restrictions (and java arrays definitely caused less trouble than java generics for the teams I’ve worked with)