Gosu Programming Language Released To Public

llamafirst writes "Guidewire Software released the Gosu programming language for public availability. 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. Gosu is provided via the Apache License v2.0. The language itself is not yet open source, although that is planned for a future community release. You can read a complete introduction to the Gosu language, a comparison to other languages, and syntax differences from Java."

Comments

Re:Another Language

[Anonymous Coward]

Perhaps it is tempting to see only encapsulation as the sine qua non in programming languages. However, a programming language does not merely make an algorithm machine readable, but also human readable (eg. yourself after 2 weeks). Therefor, the following properties are important:

- Conciseness: eg. Haskell is more suitable in representing certain algorithms, as part of the interpretter/compiler makes 'good' choices, you'd have to specify otherwise. The same goes for languages such as Prolog.
- Manipulatibility: to change a certain aspect of an algorithm (or of a whole system), we need a representation of this aspect. Aspect Oriented Programming, Lambda expressions and meta-object oriented programming are examples of this.
- Suitability to domain: whether a mathematician or a business process manager reads your code matters. Their experience and expectations differ.
- lots more...

Yes, all of it is reducable to a Turing Machine, but languages matter. A lot.

Epic type system fail - universal covariance

[shutdown -p now]

The introduction has this gem:

Gosu supports a simplified version of generics. Generics are a way to abstract the behavior of a class to work with different types of objects, but to still retain type safety. There are no wildcards, and generic types are covariant, like Java arrays, which is usually what you want.

And here's how to make the type system bite the dust with this flaw:

uses java.util.*;
var xs : List<Object> = null;
var ys = new ArrayList<String>();
xs = ys; // type system allows this blatant LSP violation
xs.add(123); // we just added an integer to a list of strings - great
print(xs.get(0)); // yeah, this prints 123 - just to be sure
ys.get(0).length(); // finally, a ClassCastException which should've happened 3 lines earlier

What's funny is that Eiffel has already fallen into the very same trap, and is still trying to dig itself out of it.

call be back....

[batistuta]

>> The language itself is not yet open source,

ok, call me back once it is. I don't really need another programming language, let alone a closed-source once.

Re:Stop It!

[poopdeville]

Since I am not CS person (Business, rather), I won't attempt to to argue with you about that.

Here is a business-like analogy: How hard is it to divide roman numerals? It's not easy. There are dozens of rules to memorize in order to make it work. Compare this to using Arabic numerals, where you only have to memorize two rules.

However, I think that any reasonable person would recognize that this Tower of Babel approach is holding back software development as a whole, needlessly fragmenting knowledge and impacting the careers of excellent programmers simply because they didn't jump on the latest bandwagon X years ago.

Yes, this is a big problem. But the issue isn't the "Tower of Babel" so much as a misunderstanding of the domains in which a tool can work well, which ultimately leads to "churn". There is an old joke along the lines of "Any sufficiently complex software project implements a buggy version of half of Lisp". There is some truth to that. Lisp is a language that allows abstraction over basically any term. This is something that imperative/OO programmers want, but they don't know how to say (and they tend to cover their ears screaming "LA LA LA LA LA" when academics tell them the problem was solved in the 1960s). So they build up ad hoc solutions to quantify over specific terms. Each of these operations is potentially tricky and buggy. The "Tower of Babel" is a consequence of this. Some of it is legitimate -- new languages can provide better tools (that is, new ways to quantify) to increase productivity. But benefits only accrue if businesses switch to them, at a potentially high cost.