As a bit of background, Gosu is based on the GScript language that Guidewire have been using for a number of years to build their Insurance application suite, so it has been proven in the development of non-trivial applications and the implementation should be more mature than a 0.7 version number might suggest.
Unfortunately for them (and me) my higher-ups at the insurance company I work for are clueless and stubborn and decided to go for a reinvent-the-wheel approach at three times the cost (our current insurance solution is based on Sun's Forte4GL http://en.wikipedia.org/wiki/Forte_4GL which, while good at the time, has been abandoned many years ago, and has no support or good IDE) .
I found it a subtle admission of fault, because: 1) It's impossible for people who know Lisp to design a language that isn't Lisp(y). 2) You can't be a serious language designer without knowing Lisp, well.
Because of #1 and #2, the author wants to align himself with the amateur school of successful language design (the people responsible for most stuff that comes pre-installed in your Redhat box.) and distances himself from egg-heads and language purists, and their potential criticism.
1) It's impossible for people who know Lisp to design a language that isn't Lisp(y). 2) You can't be a serious language designer without knowing Lisp, well.
Judging by the number of great languages that are not at all lispy, at least one of these is false.
I specifically said "amateur school of successful language design".
"Great" is subjective, but nearly all ground-breaking languages invented after Lisp are all Lisp-like (don't look at syntax.)
Industrial, imperative languages are nearly always "designed" on a whim. They're all incremental improvements over Algol, and they're probably what you're talking about if you're of the great majority of the programmers. As of late, they're more Lispy than you can imagine.
Except for a specific school of Lex & Yacc languages out of New Jersey, the great majority of professionally designed languages (i.e. by people with an appreciation for formal language design and semantics) have been Lispy and functional; characterized by clean minimal core, well specified semantics, even proven, and self-hosted implementation.
Just to throw the discussion a bone and offer some perspective; I consider ActionScript 3 "Lispy", but not AWK or C++.
How about K? It's a functional, "clean minimal core" APL with ragged arrays and lambdas. Lisp-influenced, but much less Lispy than one would expect if it's "impossible for people who know Lisp to design a language that isn't Lisp(y)".
"I much preferred implementing and coding in LISP (sic), but once I was dealing with big data sets and then having to do fairly simple calculations, APL just seemed to have the better vocabulary." - Arthur Whitney (http://cacm.acm.org/opinion/interviews/26246-a-conversation-...)
You just supported my arguments, silentbicycle; it's "much less Lispy" but not "orthogonal to Lisp". Small, expression based, self-hosting, declarative, has a core-data structure it uses to represent most of its input ..
APL, Forth, and Smalltalk might not be proper functional programming languages, but they're of the same "spirit".
Now compare this to something horribly broken, like Basic ..
I suspected as much. "Lispiness" is a fuzzy concept, though - Lua is Lispier than Python, but is Tcl more or less Lispy than SML? Etc. K is probably the least Lispy language I can think of with that pedigree.
Joy may be another exception, but it's mainly an experimental / research language.
Some Lisps are more Lisp than others; compare Dylan to Emacs Lisp. Dylan has that refined taste, that well-thought out essence, even if it's an infix, algolish language in apperance. While elisp is an orthodox Lisp, in every sense, and is unpalatable because of its true-to-form "Lispiness".
There are languages that are semantically consistent, and that's probably what I meant by "Lispy". Then there are languages which are nothing but compiler hacks; you can tell whoever dreamed them up "grew" this hairball by tweaking a parser until it did something he wanted.
Also, take a look at the Lua 5 compiler. That fucker does matrices on par with Fortran, with just 500k worth of compiler + runtime!
I particularly loved their hack for sparse matrices; they're implemented as hash-tables where the indices are zero-based integers, so only the indices that are initialized are created. Meaning, you can have an array with a few indices without having to create all the empty cells in between. I benchmarked it and it's far more than adequate. Makes graph algorithms breezy.
Each table (dict, hash, whatchamacallit) has a hash portion and an array portion, and contiguous integer keys are stored internally in the array. So, tables automatically adapt their internal implementation for use as an array, a dict, or both, at runtime. They're unique to Lua, AFAIK.
It also has an interesting hash table optimization (that I don't quite grok). I've been reading through the Lua code bit by bit, but haven't made it there yet. Lots of other interesting stuff, though.
LuaJIT's not too shabby, either!
Lua's my favorite language for quick hacks, period. I wrote a library to add fairly idiomatic pattern matching (http://github.com/silentbicycle/tamale/). Every language needs pattern matching. :) I'm still working on explaining PM to people who aren't already into Erlang or ML, but it's documented now.
Concrete examples? C and Python are prime counterexamples.
Neither are particularly "lispy" (although nearly all languages in existence have been influenced a little bit by Lisp). And yet they are wildly successful and tremendously well-designed.
So either Guido and Dennis Ritchie didn't know lisp and therefore aren't serious language designers (by your second assertion), or they did know lisp and failed to make a lispy language (which would contradict your first assertion).
If Guido and Dennis aren't serious language designers, then I'm not sure who are.
Except for a specific school of Lex & Yacc languages out of New Jersey, the great majority of professionally designed languages (i.e. by people with an appreciation for formal language design and semantics) have been Lispy and functional; characterized by clean minimal core, well specified semantics, even proven, and self-hosted implementation.
I wouldn't read too much into this. There are many more jobs for language designers in academia than there are anywhere else. So it stands to reason that most professionally-designed languages will be of the academic sort (if we can agree that a professional is someone who gets paid for their work). That doesn't imply that those languages are any better than "amateur" languages, only that there's more of them.
I really don't think we judge PLs the same way. To me C is the definition of broken, it doesn't even have proper aggregate data-types, much less a type system.
Python is a work in progress, though it improves between versions. Last time I used it, back in 1999, it was a bad calculator.
The feature list reads as "we added C# features to java": properties, type inference, lambdas, extension methods, generics without erasure, a friendly list initialization notation...
I do find the interface delegation feature interesting. Might be a good way to avoid those Demeter Transmogrifiers.
The null-safe property chains also look nice. Though I wonder if this is always the desired behavior?
I can't say for sure where they got the name "gosu", but I know from many hours of playing Starcraft with Koreans that "gosu" is the Korean word for "expert".
Just a note -- Gosu is already the name of a neat little C/Ruby graphics library that wraps up sound and graphics programming in a tiny little package that mostly gets out of your way.
(I believe it was intended for people making little games -- I've used it a few times on my own projects and it's very uncluttered, minimal etc; I used it and Chipmunk to make myself a screensaver of all of my photos falling, bouncing off of each other etc).
Indeed . . . to be fair, back when we decided to rename the language internally, we looked for any existing projects using the name, and we actually contacted the Gosu library guys to make sure they didn't mind us using the name Gosu for our language.
"you can add objects to a collection, but not primitives".
Why not?
"The collection and list classes used frequently in Gosu rely on the Java language’s collection classes. However, there are important differences because of built-in enhancements to these classes that use Gosu blocks, anonymous in-line defined functions that are not directly supported in the Java language."
It also has some type-inference that converts:
var str = {"foo", "bar", "baz"}
To
ArrayList<String> str = new ArrayList<String>();
str.add("foo").add("bar").add("baz");
We don't work around Java type erasure: if you create some object in Java and pass it off to Gosu, then that information is lost. For Gosu classes that are reified, we actually store the type parameter on the object itself, and it becomes an implicit constructor argument. For generified functions, we pass the type parameter through that's determined statically by the parser. For enhancements on generified Java classes, we also pass through the statically-determined type parameter. I.e. if you have a Gosu class Foo generified on T, when you construct Foo with type param String we'll pass the String type through to the constructor and store it on the object instance so we can retrieve it later. If you have something the compiler thinks is a List of Objects, and you call an enhancement method on List, we'll pass through Object as the type parameter, even if at runtime it's actually a List of Strings. So it's not perfect in its interaction with Java code, but it's usually good enough (and better than losing it entirely). As far as the Java classes we generate go, your generic type Foo has only one class, but as far as Gosu's type system goes, Foo parameterized on Object is a separate type instance from Foo parameterized on String.
Does this extract from the Reference Guide answer your question?
"Gosu types preserve generic type information at run time. This Gosu feature is called reified generics. This means that in complex cases you could check the exact type of an object at run time, including any parameterization. In contrast, Java discards this information completely after compilation, so it is unavailable at run time.
"Note: Even in Gosu, parameterization information is unavailable for all native Java types because Java does not preserve this information beyond compile time. For example the run time type of java.util.List<Address> in Gosu returns the unparameterized type java.util.List."
No joke. http://www.guidewire.com/our_customers lists some companies that are using the Guidewire insurance products in production. These products are all built in a combination of Java and Gosu (or GScript, as it used to be called).
[I don't work for Guidewire - I worked for an insurance company that evaluated several insurance claims packages, including Guidewire's.]
On a serious note, I'm not sure it has enough of an advantage over Scala to take a look at. Though if the type system is a bit more intuitive, that alone may propel it to the forefront of JVM languages...
If you're referring to type notation, I'd argue postfix works much better for languages that are mostly type inferred, as then there is a consistent way of declaring things.
