Gosu Programming Language Released To Public 330
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."
Sounds like Scala (Score:3, Insightful)
From a quick glance it looks like Scala with a more Java-like syntax... I wonder what added benefit they hope to bring.
I'd be very interested to see an in-depth comparison of the two.
Another Language (Score:4, Insightful)
Then one day I woke up and realized, it isn't the language, you can write good or bad code in any language. It's how you use the language, and how you organize the code that matters most. I realized as long as you have the ability to encapsulate, you can write good code in any language, even in assembly.
In fact, with a good macro library, I can write code just as fast and well in assembly as in any other language.
Or, on the other hand, maybe I've fallen into the trap represented by this saying, "The determined real programmer can write Fortran in any language." But I don't think so.
Re:Another Language (Score:1, Insightful)
You can write good code in any language but can (a) other people and (b) the compiler understand what you meant? The language enforcing the encapsulation you meant means that someone else using your code will be sure to follow it. Similarly a type system that lets you tell the compiler more about what is going on can allow for better optimizations.
You are probably right that without good style, it does not matter what language you use, but the language can help.
Re:Another Language (Score:5, Insightful)
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.
Re:Another Language (Score:4, Insightful)
But, VB makes writing bad code trivial, and writing good code challenging.
Re:Another Language (Score:3, Insightful)
Re:Another Language (Score:3, Insightful)
My point is, if you give me sufficient encapsulation tools, I can write code that is concise, readable and manipulable. And it is something anyone can do.
call be back.... (Score:5, Insightful)
>> 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:Another Language (Score:1, Insightful)
Hint: look up "assembler"
Re:Epic type system fail - universal covariance (Score:5, Insightful)
The really funny thing is that in practice all generics really need to do is prevent you from having to repeat casts everywhere, catch errors moderately soon, and aid in documentation. Which is what these do.
They don't let you "catch errors moderately soon" in many real scenarios. It's the same problem as implicit null value for reference types everywhere - end result is you can have one part of code returning null where it shouldn't, that null get quietly propagated throughout your system from component to component because no-one needs to do anything to it, and then it all finally blows up when some other code elsewhere receives a value that should not be null but is - and you end up with a NullPointerException and, often, no clue as to what code originally produced the invalid value.
Same thing here - someone, somewhere will create a collection of subtype, implicitly upcast it to supertype, and pass it over because they do not understand that List<Number> cannot always be substituted for any random List<Object> - because it's non-intuitive, despite being true (since add() is not covariant). All the evidence I need for this are all the questions asking about how to do just that in Java or C# on StackOverflow. When you ask people to post the code, it almost invariably turns out to be broken, and the type system did them a favor by rejecting it.
The real 'trap' here is thinking that something has to be theoretically perfect to be useful or convenient.
We're not talking about "theoretically perfect" here. We're talking about a language that's statically typed - the sole benefit of which is type safety unless explicitly overriden (by casts etc) - but which then forgoes this very benefit.
Furthermore, the only other language I'm aware of which has the same flaw is Eiffel. Neither Java nor C# nor any other language with generics has this. They all either have no variance at all (which is inconvenient by safe), or declaration-site variance (C# 4.0 "in" and "out" on type parameters) which is easier on the API client but does not let you express all relationships, or usage-site variance (Java generic wildcards) which requires API client to understand what it is all about.
Re:Wonder how this turns out... (Score:5, Insightful)
You have to be some kind of uber noob to think that Java and the ecosystem it has engendered could ever be called "nothing of value". There are more jobs in Java and open source projects on Source Forge in Java than in any other language. Java is not everyone's cup of tea - neither are other significant languages like C or LISP, but to pretend that Java, like any of these languages offers "nothing of value" is either arrogance or ignorance beyond belief.
I know that /. no longer caters to a technically literate crowd but you take the cake. I feel stupider for even bothering to reply to you.
Online help browser sucks. (Score:4, Insightful)
Gosu people, your help browser sucks caravans.
If I middle-click on a link, I don't want the page I'm currently reading to jump away. I want to read whatever is linked to _later_. Redirecting me and then breaking my browser's "Back" button, without even providing an alternative js back button, is unforgivable.
Re:Another Language (Score:5, Insightful)
Exactly. Which is why this "all languages are equivalent" mantra is just so much bullshit. All languages have domains for which they are more or less suited.
I don't do script-like tasks in assembler, I don't do device drivers in Java, I don't write enterprise apps in Javascript or VB. Neither do most sane software engineers. This isn't a coincidence, it's because certain tools are better at certain jobs. People who argue that it doesn't matter what language you use cannot explain why good software engineers know why some languages are inappropriate for some jobs.
Learning languages and their philosophies... (Score:5, Insightful)
It's good to learn some assembly languages to see how machines work.
It's good to learn C to get accustomed with low level things, pointer arithmetic, in-memory layout of code & data, OS internals and tons of other things. It's good to tinker and experiment with high performance C code, see how functions look disassembled. Try adding two matrixes row by row and then column by column and see performance differences etc.
It's good to learn C++ to get accustomed with it's metaprogramming facilities, learn how to implement semi-automatic memory management via smart pointers and how all these high level things interact with low level.
It's good to learn Java to get accustomed with that whole big world of objects, OOP patterns, TDD, exception handling strategies and tons of other things.
It's good to learn Scala to get smooth introduction into functional programming concepts (higher level functions, closures etc.) and see how it can be incorporated into traditional object oriented code and more interesting concurrency models (actor model for example).
It's good to learn Erlang to grasp functional programming even more, learn how to effectively use pattern matching, see the THE actor model implementation and learn about it's interesting error handling philosophy.
It's good to learn LISP to grasp it's macro system that still cannot be matched in any other language. See Common Lisp at work and Clojure for it's approach to parallelism, mutability and distinction between values and identities.
It's good to learn Haskell to see how to program in purely functional way and see monads in action.
Not that I'm in any way competent in all things above. Much of it (plus other things) is still on my TODO list. I'm still being surprised by new ideas showing blind spots of my ignorance on regular basis. I don't buy however that learning new languages doesn't matter anymore. It matters. It's important. Maybe we should choose new languages to learn more carefully, choose less but dig deeper.
Re:Another Language (Score:3, Insightful)
Hey, I'm gonna try for an analogy that is neither cars nor pizzas. Let the mod points roll !
Languages are like MP3 players: some have strong points, extra features, nice ergonomics better price.. but in the end, what counts is the Apple-like ecosystems: users, developpers, tools, PR, content...
Judging a language on its own merits is nice and all, but in the end, wuality of the tool sets, docs, hype... are probably a bigger contributing factor.
Re:Another Language (Score:4, Insightful)
How many lines do you need to emulate a Python's list comprehension statement in assembly? Even if you encapsulate, assembly simply doesn't let you express everything in the statement without a massive number of LOCs.
Higher level languages are more readable for higher level concepts. It's not the same.
Re:Sounds like BS to me... (Score:1, Insightful)
I'm all in favour of new programming languages but it's true that there are a lot around at the moment. That's why it's really important to provide a concise explanation of why you created a language when you release it to the world. What were the aesthetics informing your design decisions. What key features do you think are really important that sets it apart from its peers (ideally a short explanation of the benefit of those features too).
Gosu didn't seem to have such a clear mission statement, which makes it very difficult to know if I'm interested or not.
From what I can glean from the website a lot of Gosu seems to be about adding obvious and much needed improvements to Java, which is fine as far as it goes, but there needs to be a bit more to be truly interesting. Along those lines, I think Scala goes further and is so far more interesting to me.
Re:Wonder how this turns out... (Score:1, Insightful)
Re:Run for the hills! (Score:4, Insightful)
Re:Alright! (Score:4, Insightful)
Convince me Scala is better than Haskell. Convince me cucumbers are better than green peppers. Convince me a bucket of dirt is better than a pile of gravel.
He doesn't have to convince you of anything, because obviously you have already picked your preferred language and think that anything else is useless.
Re:Wonder how this turns out... (Score:3, Insightful)
It was runnning the original game. You should be aware that 90% of the code that is running is OpenGl and Java does not implement it. It uses a wrapper to the locally available native OpenGl libraries. So the only overhead is the JNI calls, which have been being reduced a lot on recend versions.
The point is: any language can do it reasonably well. 3d is done on the video card, not on the compiler or he VM.
Re:Another Language (Score:3, Insightful)
A compiler translates code INTO assembly (or machine code). An assembler translates assembly code into machine code.
Geez, the kids these days are spoiled with their fancy IDEs, and don't even know what assemblers and linkers are. So sad.
Stop It! (Score:2, Insightful)
Just stop with the new (but just rearranged) same old languages:
Basic,
C,
C#,
C+,
C++,
COBOL,
Dyalog APL,
Eiffel,
F#,
Java,
Javascript,
Jscript,
Mercury,
Mondrian,
Oberon,
Pascal,
Perl,
Python,
Salford,
SmallTalk,
Standard ML,
VBscript,
Visual Basic,
VisualJ++,
Really...isn't it time to rethink all of these different, but same (except for the whacko Python,PHP stuff) and come up with one standard language? Extend it with different libraries if you want, but this dreaming up a new language that is pretty much the same as all the others except the line ends with ";" or you declare the type first instead of last or assignment is "=" except when it's "==". Or iterative structures that all work the same but all have different syntax? WTF people?
Think of all the talent locked up in someone who has done language A for 10 years but is totally useless to you because your project uses language B? The concepts are the same, yet people's knowledge is arbitrarily walled off in this development environment or that environment. How can this be considered good?
Innovation doesn't mean re-inventing the wheel.
I disagree (Score:3, Insightful)
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala - Extensible type system - Easy transition from Java - Reified Generics
From those 3 points, only the last one sounds useful...
You are kidding right? In reality-land, for better or worse, #2 is probably as important of all for a lot of Java shops as #3 if not more. Type erasure sucks balls, but we can get it to work (just as we were able to write good working code without generics.)
Adoption and ease of transition are things people tend to undervalue/underestimate. Being able to leverage a language with better qualities with as little code change as possible is certainly an enormous, practical incentive. For me, I would give an eye to work on something else (Scala, Ruby/Python on the VM or Clojure), but the reality on the ground is that something like Groovy (using the Groovy++ compiler, though) is the most likely candidate for adoption given its easier transition.
Gosu seems to embrace the good qualities of next gen JVM languages (and C#) without a substantial deviation to the syntax.
Necessary /. anti-fanboy disclaimer: Before the /. fanboy crowd displays their usual lack of reading comprehension, I'm not saying that Java syntax is superior or that the syntax sported by the other JVM languages is deficient or bizarre. I'm simply stating the fact that there is an associated, practical cost of transition (in terms of education, time of getting proficiency, possible introduction of coding errors, etc) that is proportional to the syntax differences that need to be overcome - this without considering the external pressures of writing software for solving problems in the right here and right now.
With infinite time and resources, and zero friction from requirement/requirement changes and organization dynamics, syntax differences would not matter. AFAIK, that is not the context in which programming shops operate. . Another important addition is the use of delegates. Oh my, I can only think of the possibilities we currently can only do in Java with a lot of boilerplate.
Re:How precious (Score:2, Insightful)
I would love to see you develop modern enterprise apps in C++. Different languages often are suited to different tasks.
And why exactly are you so anti Java, to the extent you are making a froth mouthed fool of yourself? It's alright if you don't know how to program in Java. There is plenty of respectable, often much more cerebral, glamorous work you can do, from writing device drivers to application prgramming. What is 'your' beef?
and badly written code is not just a Java phenomenon. See http://thedailywtf.com/ [thedailywtf.com] for examples in most common languages.
Re:Epic type system fail - universal covariance (Score:3, Insightful)
Since when does the line xs=ys; not generate a warning
Are you, perhaps, confusing it with Java arrays? This is Gosu, not Java. It does not generate any warnings there, by design. In Java, the direct translation of the above would have not compiled. It would have compiled if those were arrays and not Lists, and would have not generated a warning in that case.
Re:Stop It! (Score:3, Insightful)
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.
A little yes but mostly no. A programming language isn't just syntax, it's the entire ecosystem of libraries, tools, operating system support, university teaching, and available documentation. Just as business/finance/economics has multiple sub-disciplines and "schools" that are appropriate to different business situations, so does each major programming platform lend itself to creating certain kinds of applications. Saying "let's use programming language X to solve problem Y" is just as foolish as insisting that Six Sigma will always produce the same business outcome as LEAN.
If you must pick one thing that's holding back software development as a whole, pick human nature within business organizations. The story of LISP shows what happens when one programming language is "too powerful": managers didn't want to replace ten conventional Fortran/C/Pascal/etc. programmers with one good LISP programmer because it would simultaneously lead to that one LISP person being irreplaceable and the manager himself/herself becoming redundant. Contrast with the story of Java, a language deliberately restricted in order to enable lower-skill developers to produce something of value: Java was incredibly successfully precisely because it did not create a business dependency on ultra-productive irreplaceable programmers.
The "Tower of Babel" is only bad for the first few years of a general-purpose (not assembly language) programming language, when it needs to grow its compiler/interpreter and base libraries for common things like networking, threads, OS integration, GUI support, math, crypto, and basic algorithms. After that it becomes just another tool that may have good uses for certain situations. Every good programmer will have at least half a dozen such languages in their toolbox: mine includes C, C++, Perl, bash shell script, Java, Common Lisp, and Clojure, and I am adding to that D to eventually replace most of my use of C++ and Java.
Re:Stop It! (Score:5, Insightful)
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.
Inexperienced Programmers (Score:3, Insightful)
Think of all the talent locked up in someone who has done language A for 10 years but is totally useless to you because your project uses language B? The concepts are the same, yet people's knowledge is arbitrarily walled off in this development environment or that environment. How can this be considered good?
Innovation doesn't mean re-inventing the wheel.
Sounds like inexperienced programmers. The first 10 languages you learn are challenging, after that it's all syntax and frameworks.
Now then, some languages are bundled with extremely baroque and quirky frameworks which can suck up most of your development time. But this language is actually doing it right - by being Java-compatible on the JVM, the programmer can recycle his Java Library knowledge. Parrot is another similar approach, where Perl, Python, Ruby, etc. programmers will be able to trade libraries.
The bigger problem list is probably:
JDK,
CPAN,
Gems,
STL,
PyPi,
etc.
These might be worse - they're largely duplication of labor, whereas the languages are at least trying to do something different.
Re:Stop It! (Score:3, Insightful)
In Python:
mycounter = 0
That's not just a syntactic difference, and it's not just assigning a value to a variable. Instead, it's creating an int object with a value of 0 and binding the name "mycounter" to it. Since Python objects have types but variables don't (as they're all basically pointers to objects), there's no type declaration necessary - or even feasible without significant ugliness.
In turn, you're missing my point in that these aren't just cosmetic differences that a little bit of syntax unification can hide. For instance, you include languages on your list that implement single assignment [wikipedia.org] and don't really support (or at least don't encourage) variable assignment in the sense you're describing.
Re:Stop It! (Score:1, Insightful)
or a new form of mathematical notation in order to learn/work within those different areas.
No, you don't, because business is a fundamentally social enterprise, whereas programming is a fundamentally mathematical one. There's a reason why all of the different branches of mathematics use different (and sometimes infuriatingly similar) notation - no one ur-notation can express it all and still fit inside a human brain.
Re:Stop It! (Score:4, Insightful)
"Clojure" and "D"?
Just shoot me now.
Why are you so hostile to learning? Clojure is a modern "Lisp done right", with all of the syntactic power of LISP minus quite a bit of historical goop, running on a very modern JVM with the goodies that that provides (the massive portfolio of Java libraries and mostly platform independence). D is a very modern "C++ done right" that is very well-suited for applications where you need the ability to occasionally shoot yourself in the foot (i.e. high performance, constrained memory, low-level access) but most of the time would like to use higher-level conveniences like garbage collection and templates.
One thing about the multiple sub-disciplines and "schools"...they all use English.
Sure, they all use English, but they don't say the same thing. (And actually many of them don't. Business is global these days.)