Just an aside, Java had generic type inference since 8, and has local variable
type inference in Java 9.
Personally, I hate type inference. I find myself continually needing to refer
to the docs to know what something is, when type inference is not used this
doesn’t happen as the code is self documenting. I think type inference is lazy.
Puts the burden on the maintainer forever when it would of been a small effort
up front. For things like lambdas it makes a bit more sense but barely.
Sent from my iPhone
> On Sep 23, 2018, at 11:43 PM, Ian Denhardt <i...@zenhack.net> wrote:
>
> 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.
--
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.
