[OFFTOPIC] Xtend for Go

[Bienlein]

Dudes,

I have a cunning plan ... Create some programming language on top of Google's Go using Xtext the same way Xtend is created on top of Java. Add inheritance to Go as far as possible and templates. That would result in a real cool language for concurrent programming.

Okay, this is not exactly the right forum for this kind of matter. But I don't know of any other place to ask how difficult this superset language of Go wold be to develop the same way Xtend was developed (say just templates to begin with). Any hints appreaciated and sorry for "misusing this forum".

Regards, Bienlein

[Lieven Lemiengre]

It's certainly possible, I think that the hardest issue that you may have is interacting with existing Go code and modelling all the subtleties of the Go type system, if you want to be able to do this.

As an xtext developer (~3 years, every day) of a commercial IDE for a 2 very big languages, I can tell you that the required expertise to take up a project like this is considerable. Xtext fantastic to quickly create small DSLs that compile to java (using xbase) or something else if the transformations are simple. You want to build a general purpose language with it's own typesystem & expressions and map this to an existing language, to do this you need to be very familiar with the inner workings of xtext.

To get a grasp of what you are trying to do, watch this presentation, they are trying to do something similar for javascript: https://www.youtube.com/watch?v=Xm-7aE1UMGY

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Diot]

On Monday, July 7, 2014 1:45:18 PM UTC+2, Bienlein wrote:

Add inheritance to Go

I thought the big problem with Go, compared to Java, was lack of Generics and no Exception-Handling? I did not realize Inheritance is missing too. It doesn't sound to me like any amount of wrapping would make it into a great language, in it's current state.

[Christian Vogel]

I'm no expert in Go, but having done their tutorials, I got the impression that one of the best aspects of Go is their inheritance based on behavior instead of subclassing. Aren't you breaking one of the very parts that makes Go an interesting language? (asides from the lovely native channels/continuations)

[Bienlein]

Hi there,

my comments below ;-)

Am Montag, 7. Juli 2014 20:54:45 UTC+2 schrieb Christian Vogel:

I'm no expert in Go, but having done their tutorials, I got the impression that one of the best aspects of Go is their inheritance based on behavior instead of subclassing. Aren't you breaking one of the very parts that makes Go an interesting language? (asides from the lovely native channels/continuations)

Well adding templates to Go won't break channel or goroutines. Whether exception handling is a good thing or not is a very difficult issue. Requires too much knowledge of compiler construction and language design that I could follow. Anyhow, there are good reasons not to have exception handling. That Go does not have them is on purpose and not just a sign for the language being simple. Swift also does not have it, but it is probably because exceptions being thrown would make the instance counters used for ARC become corrupted.

Since Go does not have dynamic dispatch there is no way to implement method overwriting (overwriting the inherited method) without changing the compiler. The reason Go does not have inheritance (no method overwriting, no inheritance) is that Robert Pike is known to dislike OOP. What is called "embedding" in Go is in OOP terms nothing but delegation. Groovy has for example the @Delegate AST transformation which is a very similar thing.

Whether lack of inheritance is a good thing or not is questionable. Not being able to overwrite an inherited method removes a great deal of flexibility and it does not cost that much performance as C++ shows. Have a look at at the following Go code taken from here:

type Base struct {}
func (Base) Magic() { fmt.Println("base magic") }
func (self Base) MoreMagic() {
  self.Magic()
  self.Magic()
}

type Foo struct {
  Base
}
func (Foo) Magic() { fmt.Println("foo magic") }

f := new(Foo)
f.Magic() //=> foo magic
f.MoreMagic()

The question is now what the last line f.MoreMagic() prints to the console. If inheritance were present (and hence method overwriting) it would print "foo magic foo magic". But it prints "base magic base magic". To verify this you can run this code: http://play.golang.org/p/q52lvTFPQ6