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."
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.
PageTurner Reader: open-source e-reader for Android with cloudsync. http://pageturner-reader.org
At one time in my programming life I liked learning languages, I made it my goal to learn pretty near every interesting language from APL to FORTH.
:)
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.
Qxe4
>> 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.
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.
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.
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.
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.
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.
Honestly the main issue with java is when and how people use it. To give an example of when not to use java: You don't want to be writing a heavy 3D game engine in java, sure it'll work. But C++ will be a lot faster (to the point where it's clearly visible to the user). At that point you have to wonder if java is the correct solution. C++ might offer a bit more difficulty to write the initial program and will punish you more severe if you do make a mistake. But the end result is worthwhile. Java is good for office applications, 2D games and other non-CPU and graphics intensive tasks. On the how people use it issue,they wish to force the object oriented on everything. Objects used right make code easy to manage and read. Objects used wrong add several layers that you have to fight your way through when debugging. Not to mention as java is compiled to byte code that keeps most of the original code in the same structure. This means you'll actually have to go through that much layers of objects to execute something. On the other hand in C++ the optimizer will most likely try to take care of it and reduce the complexity. This is what annoys me about most java programs in fact. They use a large amount of objects just cause they can, not cause they should. Simple procedural code is often easier to read and faster in most cases, so why bother wrapping it in an object of its own and then calling it from within the object?
Which is good, because it teaches programmers the positive impact white space has on readability
-- dnl
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.
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.
-- dnl
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.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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.
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/ for examples in most common languages.
A new revelation every day
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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)