Go-like interfaces + multi-methods make sense?

Question

Thinking about the design of a potential new language, I wonder how related are the concepts of built a OO similar to GO interfaces and multi-methods (I get this from http://docs.julialang.org/en/latest/manual/methods/).

If I understand this right, the interfaces are simply a group of methods that must be implemented by each descendant, and multi-methods provide a nice way to specialize them without do a lot of boilerplate or casting.

However, Is my intuition that both could work well together, but wonder if is correct. For example, if a interface declare:

type Animal interface {
    Speak() string
}

func (d Dog) Speak() string {
    return "Woof!"
}

but in julia is more like:

speak(x::Dog) = return "Woof!";

So this feel like that both do the same, but different. Will be a mess to do both? When could that make sense?

Also, what make a "better" path, if only one must be used?

Answer 1

Given that languages already exist that bracket the possible behaviours you are considering, the question is: which would suit your users better?

To create a programming language you need an intended audience of developers who will use it. When you ask a question of this type you then ask which choices will suit your intended users better.

If your users come from a specific community (say converts from C, C++, C#, Java, Go or Julia) then you choose to either provide something familiar, or something with specific benefits. Read the Go rationale to get an idea of how that works.

If your intended users are academics, or language freaks, or language dilettantes, then you strive to provide something novel and interesting, whether it is useful or not. A language like Befunge comes to mind.

If the only user is yourself, do what you like. Literally.

My audience has always been developers who want their lives made simpler by hiding unnecessary detail. The Julia approach looks pretty good to me. I can't tell you what the consequences will be until I know who your users are.

---

So if the target is developers that do business apps, web backends, mobile and you want to make their lives easier, then take an app written in some language and see how you would rewrite it in your new language in (say) half or a quarter or a tenth of the lines of code. What detail will you hide? Where will you hide it?

Scripting languages like python/perl/ruby are implemented in C/C++. They hide things like memory allocation, pointers, hashes and linked lists, string searching, loops by using garbage collection, references, associative arrays, regular expressions and map/apply logic. The code is still down there in the runtime, but the language operates at a higher level.

Maybe you can take concepts like these are move up to an even higher level with declarative code, goal-seeking and pattern matching, but that would be an entirely different question.

Answer 2

I really want to encourage you to do this. It sounds interesting and maybe new (I did not research).

I can tell you two reasons why:

Go-like interfaces over Java-like interfaces?

Suppose I create a new interface for all object that can "read". Objects of the standard library comply to it. But in Java, this interface has to be know to the standard library. Two equal interfaces can be equal but not the same. To comply to an others interface you need to adapt the code of the standard library. This may be hindering if you have a very decentralized development process. Example

Multimethods with Interfaces

An interface is not a type. You will get troubles (good troubles) with identity.

Interface Dog {bark()};
Interface Wolf {bark(); pack()};

multimethod a(Dog);
multimethod a(Wolf);

// calling a
a(aWolf) // a wolf has the same ablilities as a dog. Which method to choose?

I would like to see a solution that is understandable.