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.
Here is a decent early interview https://www.javaworld.com/article/2076012/core-java/a-conversation-with-james-gosling.html <https://www.javaworld.com/article/2076012/core-java/a-conversation-with-james-gosling.html> and an excerpt: The role of simplicity Venners:The opposite of complexity is simplicity. I have often heard you describe your philosophy when designing Java in the early days: you didn't put something in Java unless five people screamed at you and demanded it. In one interview, you told this really good story about moving to a new apartment and something about keeping things in boxes. Gosling:That's actually a general principle for life that works really well. When you move to a new apartment, don't unpack. Just sort of move in, and as you need things, pull them out of the boxes. After you've been in the apartment for a couple of months, take the boxes -- don't even open them -- and just leave what's in there and throw them out. Venners:The 'don't even open them' part is important because it's very hard to throw things away once you know what they are. Gosling: Right, because if you open them, you say, 'oh, I can't part with that.' Venners:So would you say that simplicity is a general philosophy programmers should always have when designing programs? Gosling:I think in any kind of design, you must drive for simplicity all the time. If you don't, complexity will nail you. Dealing with complexity is hard enough. In programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don't understand it. So one of the most important criteria for judging a design for me is the manual. Is the manual out of control, or is it reasonably concise? You can write a pretty decent Java manual in less than 100 pages. The current Java language spec is pretty thick, but that's because it's probably the most detailed language spec ever written. It goes through all of the details. I couldn't write the Java language spec. > On Sep 23, 2018, at 3:34 PM, Michael Jones <michael.jo...@gmail.com> wrote: > > You did not offend me. This is a place for earnest ideas and all are welcome. > > Your comment is not yet persuasive, but it might become so. Still thinking. I > first heard from James Gosling about Java when Java was Oak. He seemed proud > to say, "C++ has objects. Well, I'll show them, I'll make everything > objects!" That they did. I've been recalling those days and wondering if that > team knew more about language design in some privileged way or was just > turning the knob to eleven. Still not sure. > > I am sure that Alan Kay et al had important, fundamental insights in > Smalltalk. Variables had named attributes and they could be inspected in code > and visually with an inspector. I could ask you about your type, size, > length, etc. If i asked an inapplicable question i got a survivable answer, > not a panic. I raised this pre-Go1 in Google with the idea of, why are Len() > and Cap() not implicit methods on a slice? I like that because it also > suggests asking a variable, "hey, what is your minimum expressible value?" in > a way that is type agnostic. Being able to as parameter t of generic type T a > question like "x := t.MinExpressibleValue()" has a grand flexibility compared > to a type switch that then knows about library functions for > math.MinFloat64(). There were reasons why not, but in this quest I'm not > persuaded against the notion that every common attribute of T should be > knowable from t, an instance of that type. In Go this happens with magic > compiler generics (len(x), cap(x), ...) that take any and all types and do > the right thing. I'm more a fan of no magic and a simple universal notion > that applies to every type, built-in or custom. > > In this sense, the Java team's gusto and my deep respect for Smalltalk's "a > queryable database of instances" (aka, DOM decades before) align and I do > like that path. > > On Sun, Sep 23, 2018 at 9:17 AM Robert Engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > I take offense to that. I apologized for my statement that was worded more > harshly than intended. But if you think that Go is beyond criticism just > because of ??? Anything??? Go is a GREAT tool for many classes of > applications, but it is certainly not appropriate for all use cases. Maybe > with open criticism it could get there, but I don’t think your attitude will > help it. I am certainly not the first nor the last to highlight many > deficiencies in Gos design. That’s the great thing about software though, it > is malleable. > > Sent from my iPhone > > > On Sep 23, 2018, at 9:01 AM, Lucio De Re <lucio.d...@gmail.com > > <mailto:lucio.d...@gmail.com>> wrote: > > > > I take exception to that statement, your notion of "understood > > languages much better" doesn't parse in light of the fact that you are > > here, debating the merits of Java in the primary Go forum instead of > > writing wonderful code using the language you respect so much. > > > > That's either hypocritical or merely absurd in addition to the rather > > inappropriate, unjustified and offensive ad hominem that accompanies > > it. > > > > Lucio. > > > >> On 9/23/18, Robert Engels <reng...@ix.netcom.com > >> <mailto:reng...@ix.netcom.com>> wrote: > >> Issues like these highlight the deficiencies of Go compared to Java. The > >> Java designers understood languages far better, and from the start realized > >> that identity and reference equality were different concepts. Everyone in > >> Go > >> land are debating these solved issues. Pick and chose what you want to > >> implement but there doesn’t really need to be a debate on how to do it. > >> > >> Sent from my iPhone > >> > >>>> On Sep 22, 2018, at 8:52 PM, Ian Denhardt <i...@zenhack.net > >>>> <mailto:i...@zenhack.net>> wrote: > >>>> > >>>> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote: > >>>> > >>>> I think the thing everyone who likes operator overloading like mainly > >>>> is being able to do infix and postfix syntax, instead of only prefix > >>>> (function). > >>> > >>> My own reason for wanting this is not really about syntax, so much as > >>> being able to define functions etc. which e.g. check for equality, > >>> without having to write too versions -- one that uses `==` and one > >>> that calls some method custom types. The syntax isn't really the point; > >>> there's an underlying notion of equality that we want to be able to talk > >>> about for more than just built-in types. We could define an interface > >>> for this: > >>> > >>> // The Equatable interface wraps the basic Equals method. > >>> // > >>> // x.Equals(y) tests whether x and y are "the same." The predicate > >>> // Equals should obey a few common sense rules: > >>> // > >>> // 1. It should be reflexive: x.Equals(x) should always return true > >>> // (for any x). > >>> // 2. It should be symmetric: x.Equals(y) should be the same as > >>> // y.Equals(x) > >>> // 3. It should be transitive: if x.Equals(y) and y.Equals(z), then > >>> // x.Equals(z). > >>> // > >>> // It generally does not make sense for a type to implement > >>> // Equatable where the type parameter T is something other than > >>> // itself. > >>> type Equatable(T) interface { > >>> Equals(T) bool > >>> } > >>> > >>> What I am suggesting is merely that `==` desugars to a use of this > >>> interface. > >>> > >>> An important litmus test for any operator we consider for overloading is > >>> whether we can come up with a clearly specified interface for it like > >>> the above. If not, it does not make sense to allow the operator to be > >>> overloaded, since it is not clear what overloaders should do. I believe > >>> this is the source of most of the problems with operator overloading in > >>> other languages. > >>> > >>> I think if we stick to this things will stay under control; there's > >>> currently nothing stopping folks from defining an instance of > >>> io.Writer that does something utterly in conflict with what is described > >>> in its documentation -- but that hasn't seemed to be a problem in > >>> practice. > >>> > >>> Quoting Michael Jones (2018-09-22 13:14:21) > >>>> the reason i wrote something like "...operator overloading, but wait, > >>>> don't get excited..." was to bring awareness of a core problem without > >>>> (hopefully) having people bring the burden of experience. i say burden > >>>> because bad experiences can shadow the 'why' that was good with the > >>>> 'how' that was bad. let the why foremost to "break these chains, rise > >>>> up, and move beyond" as in Callicles' famous speech. > >>>> the essential meaning of operator overloading and go interfaces and > >>>> Smalltalk messaging is a way to bind code to intent. (in general > >>>> intent > >>>> is named uniquely ("==") for simplicity but that is independent.) > >>>> Generics raise the need a way to say how the standard intentions play > >>>> out for our types. Imagine our gopher attired as a waiter, politely > >>>> asking questions of a custom type: > >>>> > >>>> gopher: Will you want to test for equality, madam? > >>>> > >>>> type: Yes, thank you. > >>>> > >>>> gopher: How would you prefer that test to be done? > >>>> > >>>> type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now. > >>>> > >>>> gopher: very good, madam. > >>>> > >>>> This mutual understanding needs to happen. how is open to discussion. > >>>> go interfaces use standard method names. operator overloading uses > >>>> standard symbols. macro expansion uses arguments. no matter how it > >>>> manifests, the power of generics relies on understanding related > >>>> parts. > >>>> we should talk about what kinds of parts deserve awareness. > >>>> > >>>> On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio.d...@gmail.com > >>>> <mailto:lucio.d...@gmail.com>> wrote: > >>>> > >>> > >>>>> It's good that you brought that up, because another issue I > >>> remember > >>>> from C++ V1.0 days, is that operator overloading did not allow for > >>>> changes in operator precedence, an arbitrary sop to some weird > >>>> decisions taken in earlier centuries. What I see as pertinent here, is > >>>> that precedence is yet another "type" property, this time not of the > >>>> arguments to an operator, but the operator itself. > >>>> As I pointed out in private correspondence to Ian Taylor, the entire > >>>> mess of arithmetic operations ought to be delegated to an APL-like > >>>> interpreter and all the complexities, of which being "generic" > >>>> functionality is not the only one, becomes one less problem for the Go > >>>> compiler. If APL is too obscenely obscure in the Go context, no doubt > >>>> there will be alternatives: it did not take Rob Pike long to produce > >>>> Ivy. > >>>> Of course, we also have indexing, indirection and a few other features > >>>> of Go whose role could be examined and formalised, perhaps more > >>>> successfully once the obscurity contributed by the arithmetic features > >>>> is expelled from the language. > >>>> Ian's response will remain with me for as long as I live, as I think > >>>> it > >>>> is very apt summary: that would not be Go. I entirely agree with him. > >>>> � > >>>> > >>>> But then also what do you do about interfaces that also implement an > >>>> operator interface? I'd guess biggest reason to not do it is� > >>>> 1) no human readable distinction between actual operations and one has > >>>> to decompose the code quite a lot as both types have to be known > >>>> before > >>>> you can attach it to an interface > >>>> 2) there is very few cases where being able to use infix operators > >>>> makes that much difference to readability, it's like you want some > >>>> mathematical notation but it's still all in lines. Chaining > >>>> pass-through methods works just as well and the types are much easier > >>>> to identify before you even fully parse it. > >>>> > >>>> Once we treat mathematical expressions as orthogonal to the language, > >>>> we get brand new choices, possibly opportunities: what is Boolean? > >>>> What > >>>> is a string that is not an array? Etc. A whole new chapter opens, for > >>>> better or for worse. > >>>> Lucio. > >>>> > >>>> -- > >>>> 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 [2]golang-nuts+unsubscr...@googlegroups.com > >>>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > >>>> For more options, visit [3]https://groups.google.com/d/optout > >>>> <https://groups.google.com/d/optout>. > >>>> > >>>> -- > >>>> > >>>> Michael T. Jones > >>>> [4]michael.jo...@gmail.com <mailto:michael.jo...@gmail.com> > >>>> > >>>> -- > >>>> 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 [5]golang-nuts+unsubscr...@googlegroups.com > >>>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > >>>> For more options, visit [6]https://groups.google.com/d/optout > >>>> <https://groups.google.com/d/optout>. > >>>> > >>>> Verweise > >>>> > >>>> 1. mailto:lucio.d...@gmail.com <mailto:lucio.d...@gmail.com> > >>>> 2. mailto:golang-nuts+unsubscr...@googlegroups.com > >>>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com> > >>>> 3. https://groups.google.com/d/optout > >>>> <https://groups.google.com/d/optout> > >>>> 4. mailto:michael.jo...@gmail.com <mailto:michael.jo...@gmail.com> > >>>> 5. mailto:golang-nuts+unsubscr...@googlegroups.com > >>>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com> > >>>> 6. https://groups.google.com/d/optout > >>>> <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 > >>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > >>> For more options, visit https://groups.google.com/d/optout > >>> <https://groups.google.com/d/optout>. > >> > >> > > > > > > -- > > Lucio De Re > > 2 Piet Retief St > > Kestell (Eastern Free State) > > 9860 South Africa > > > > Ph.: +27 58 653 1433 > > Cell: +27 83 251 5824 > > FAX: +27 58 653 1435 > > > > -- > Michael T. Jones > michael.jo...@gmail.com <mailto:michael.jo...@gmail.com> -- 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.
