Re: [9fans] xml

[Jorden M <jrm8005@gmail.com>]

On Thu, Jul 1, 2010 at 2:49 PM, Rob Pike <robpike@gmail.com> wrote:
>> `Interfaces', the way they are invariably implemented, don't cut it --
>> too limiting and imposing.
>
> I do not claim that Go's interfaces can match the type system of
> Haskell but this sentence tells me you aren't very familiar with them.
>  They are not implemented, invariably or otherwise, like any other
> things called interfaces that I know.  They also don't work very much
> like the same-named things in other languages.
>
> As for limiting? Maybe. Imposing? Not at all. If anything, I'd call
> them liberating.
>
> As Russ said, there's more new in Go than many observers seem to
> realize.  The language looks much more traditional than it really is.
>
> -rob
>
>

I wasn't making a particular statement about Go, as I am not that
familiar with it. Syntactically, it's eerily similar to Algol, but
obviously there's more to a language than syntax. We all know how
sweeping generalizations are.

Go's interfaces definitely cut down on coupling compared with, let's
say Java and C++, since they're fun to beat on. I am left to wonder if
the implicitness of Go interfaces causes problems until I explore the
language more. Lack of polymorphism in the interfaces seems to limit
the extent to which they can be compared to Haskell type classes, but
it seems safe to say that they are definitely a subset.  Being a bit
more general than Go is with the kinds of function types a
class/interface can specify seems incredibly useful, so, limiting,
yes. Imposing... perhaps not. But I wasn't interested in starting a
`my typesystem can beat up yours' non-discussion, just pointing out
something that seems to have a lot of functionality while still being
incredibly elegant compared to alternatives. Haskell manages to think
farther outside the box than just about everyone, and we'll need a lot
of that as the multicore roll-out continues.

In any event, these kinds of square-peg-round-hole comparisons are
always subject to the Turing-completeness reductio ad absurdum so I
guess it's best not to look too deeply.