Quoting robert engels (2018-09-23 22:50:54)
> I'm often confounded when people discuss Java (at least in comparison
> to Go) as being "heavy". If you read early interviews with Gosling it
> is clear that his design was more about what to leave out, not what to
> include (macros, pre-processor, unsigned arithmetic, etc.) He is a
> brilliant language designer, probably top 10 CS engineers, and I think
> he's worth listening to. I think as people look to "enhance/improve"
> Go, his thoughts and processes might be of value.
I feel like a lot of the complaints about java being "heavy" comes down
to sheer verbosity, some of which is an artifact of the language itself
(no type inference whatsoever), and some of which is the way APIs tend
to be designed; you have lots of identifiers that are like six words
long, everything feels very pedantic a lot of the time. I've found java
to be painful to write without an IDE and autocompletion (like,
*physically* painful -- my bad pinky starts acting up after a while).
None of this is really about the complexity of the language per se. But
much of the discussion in this thread is about what kind of code we'll
see in the wild if we add operator overloading to Go. I think Java is a
good illustration of what that can do to a language. We could delve into
what actually went wrong there, but the point is we need to think things
through.
It seems like Gosling had the right attitude re: simplicity,
but somewhere something fell apart.
I wasn't really around for the days when folks thought Java was this
great simple thing. I started my CS bachelors' in '06; by then Java
already had generics, and they felt very bolted on. They didn't really
work with some of most commonly used types in the language (int,
bool...). Java had this mantra of "everything is an object", but it
rang hollow in light of that. So many aspects of the language seemed
slapped together even then, when I had no basis for comparison. The
subtyping rules for generics are different than the ones for arrays,
because somebody failed to think through the implications of the array
subtyping rules. This program tries to put a string in an array of
integers:
class Main {
public static void main(String[] args) {
Integer[] myInts = new Integer[10];
Object[] myObjs = myInts;
myObjs[0] = "Hello, World!";
}
}
It typechecks! and when you run it, you get:
Exception in thread "main" java.lang.ArrayStoreException: java.lang.String
at Main.main(Main.java:5)
By the time generics got added, that hole in the type system had bit
people enough times that they didn't make the same mistake again. But
it's another dark corner of the language that was frustrating to have to
explain to undergrads years later when I was a TA. Not long after, the
department just started teaching them Python instead.
There are two lessons here, one about type theory and one about design.
The design lesson is that "lets keep things simple," while a great
principle, isn't a substitute for thinking through the details, and
maybe even doing the math.
The good news is that as we look at adding generics to Go, we have a
much easier problem than the designers of Java did. The interactions
between subtyping and parametric polymorphism are notoriously subtle and
complex, and it's not surprising that smart people made the
aforementioned mistake. I think some of the perceived weight of Java's
generics comes from these complex interactions.
But while Java has pervasive subtyping everywhere, Go barely has
subtyping at all, and I have a hunch that the bits that look like
subtyping at first can be formalized in terms of constructs that play
much more nicely with generics.
We can do this right, and have generics in Go be simple and feel like
they belong there. But the current contract-based design is a
non-solution. It's clear to me that we should be using interfaces
instead, and that need something like operator overloading to make this
work.
I have a sketch of a design for the system in my head; hopefully by the
end of next week I'll have time to write it down and share it.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
