Choosing a virtual machine target was the wrong decision. All machines have
a machine in them, why add a virtual one? C already could be compiled on
every platform, all we got out of it was processing latency and a whole
extra layer of performance wrinkles that the CPU maker probably already
fixed.
It's my opinion that if you really think that Go is missing generics you
just don't know the language well enough nor have used it to solve problems
others used parametric polymorphism or generics.
The clamour for solutions in the area of error handling and (easier)
generic programming for go has to do with the wordy constructions required
to implement data abstraction. To speak of java, it also has the interface,
and was the biggest champion of the concept for a long time.
But it's not the feature everyone talks about Java. That's the JVM on every
processor and the OOP constructions, as everywhere else in programming
there is no interface.
But interfaces can solve a lot of these problems and cut down on
boilerplate, and Go's stdlib already has loads of good though
unsophisticated examples of interface programming.
Also in this discussion people are talking about how languages like
Smalltalk have deep reflection capabilities. Go has 'reflect'. and go has
interfaces. You can often dodge a lot of use of reflect by using
interfaces, and *making* types with more metadata is not difficult with Go,
at all. The error inbuilt interface, for example. It is extremely
primitive. The way it should be used is that you declare (almost) all types
as structs and add the attributes you want to them and create interfaces
that pass and process this data. Then you can use the dot notation to form
ad hoc constructors, you can create second level names using structs, and
the thing I have discovered is that once you have a really good set of
interfaces for things like coding modes, error handling, and so on, when
you go to actually write the application you can say a lot with quite a
little.
The downside of this complexity-averse philosophy in go is that even though
the concept is not that young, I think there is some ways to go before the
best patterns for interfaces are a settled question. What I love most about
interfaces is they let my code start to look more like poetry and less like
math. Maintaining code is very important, and though in some areas Go can
be quite wordy, the constructions are quite naive and are not difficult to
edit en masse, the invention of multiple cursors in editors is something Go
programmers can greatly benefit from. Repetition is bad if it says nothing
new but at the same time it is easier to unfold what it contains when it is
in a simple syntax, and easier to generate automatically. Code generators
are another thing I have started looking at, and I know there is a lot in
there that would make this type of programming simpler. Turning a struct
into JSON that can be unmarshalled using reflect does not require reflect,
a simple string concatenation with some string conversions, which is just a
bit of array shuffling. The same applies to database serialization. In go
many times you can gain a lot with the use of some of the wordy stuff, and
then afterwards you have a neat little black box that you can trust, and
never have to use that wordy stuff unless you are just building something
new without a clear map of its parts.
Go puts a lot more power in the hands of the programmer, and doesn't sugar
over very many things at all. Whether it reads well and is comprehensible
is more dependent on the programmer than the language, but the benefit is
being able to ride so close to the metal whenever you need to, and a neat
construction system to give more flexibility and power.
It's my opinion that when you start to try using interfaces and goroutines
in new ways you have less bad to say about what is sacrificed for this
power. I kinda basically wasn't programming much during the time of the
rise of OOP though it seemed cool when it came out, I was just used to
BASIC and assembler and my favourite language back then was called "E",
which, similar to Go, combined a very simple syntax, mashed together some
syntax patterns from C and Pascal style, but man that compiler flew, it
felt like nearly as fast as assembler.
Keeping the compilation process simple does mean the programmer must adapt
their thinking to be more like the machine, but on the flip side, you can
run through files and make multiple changes easily, with no ambiguity of
symbols, search and replace and multiple cursors, quite quickly, and
immediately see the change, plus, more easily write tools that parse it.
There is many tools already, but the maturity of the field of automated
programming isn't mature yet, in my view. Instead of wanting go to
sacrifice that speed and simplicity so you can read your code easier, you
will just use some declarative focused, maybe mixed embeds of code, add the
ability to know which is which with the editor to parse it live in the
background and you'll be scratching your head wondering why you wanted to
sacrifice the benefit of fast and deterministic compilation at all. Look at
what is happening in the world of Javascript... 90% of the code these days
is running as JS, but probably 80% of it is generated by javascript
translators, and how declarative they are. Nothing is stopping the use of
this. Either in code generators or in frameworks that process these
descriptions during runtime.
Go makes all these things even easier than javascript, has nearly as much
expressive power alone as java, and we are only at 11 years since the first
version. Java and Javascript most especially show that tooling is more
important than the language itself for adoption, most especially
javascript. Go has the potential to be a way to distribute software purely
as source code and have it always run as native binary. It's hard
limitations also make it very safe. So it is just the absence of these
tools being built that is holding it back. Too often people are more busy
coding to order and not coding to develop the toolkit. Go needs more tools.
Layers that allow patchworking of declarative systems that bone out a
pattern and then give you all the slots where you need to put the
non-structural stuff.
On Sunday, 23 September 2018 22:34:50 UTC+2, Michael Jones 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 <ren...@ix.netcom.com
> <javascript:>> 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...@gmail.com
>> <javascript:>> 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 <ren...@ix.netcom.com <javascript:>> 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
>> <javascript:>> 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...@gmail.com
>> <javascript:>> 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...@googlegroups.com <javascript:>
>> .
>> >>>> For more options, visit [3]https://groups.google.com/d/optout.
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Michael T. Jones
>> >>>> [4]michae...@gmail.com <javascript:>
>> >>>>
>> >>>> --
>> >>>> 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...@googlegroups.com <javascript:>.
>> >>>> For more options, visit [6]https://groups.google.com/d/optout.
>> >>>>
>> >>>> Verweise
>> >>>>
>> >>>> 1. mailto:lucio...@gmail.com <javascript:>
>> >>>> 2. mailto:golang-nuts+unsubscr...@googlegroups.com <javascript:>
>> >>>> 3. https://groups.google.com/d/optout
>> >>>> 4. mailto:michae...@gmail.com <javascript:>
>> >>>> 5. mailto:golang-nuts+unsubscr...@googlegroups.com <javascript:>
>> >>>> 6. 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...@googlegroups.com <javascript:>.
>> >>> For more options, visit 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. jonesmichae...@gmail.com <javascript:>*
>
--
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.
