Yep, you are correct, more or less. My code is using interfaces and
panicking when it's fed the wrong thing.
For example, in my test I had a literal number going into a write function
to put a value into a node in the tree. The insert implementation panicked
saying it couldn't put an int into a uint32 slot. Eventually I worked out
it was the assumed int typing of the literal causing the problem (happens
all the time, I should be used to it by now).
The thing is, it is intended that the user of the type specific library
that imports the tree library will not make a type assumption like the
compiler did about a literal. The type specific part has to be written for
any given type. There is a little verbosity in the part that wraps the
injected functions with syntactic sugar so the base library has the
functions to work on the concrete data agnostic of its content and only the
return values provided by the functions it gets to do various comparisons
and whatnot. It's not excessively wordy for my tastes and I know it's doing
it the best way possible.
It's just learning how to play with interfaces that I was struggling with
and I seem to have pretty much got it all figured out now. I'm happy with
how the code is developing and pretty much joyous that I can do this inside
a type safe language. Type safety is a big part of how Go is such a fast
compiling language. Implicit casts and inheritance have a massive cost in
complexity not just a naive translation to binary code, but also in
optimising it. When can it cut out the dereferencing to methods and when
not? Since one could be using a method to do a relatively simple thing, in
very long, tight loops, if the OOP compiler guesses wrong and puts
dereferences in where they are not needed, it's a big cost over 1 million
iterations compared to being aware of it, like in my code, and avoiding the
need for dereferencing.
I firmly believe that Go could replace C as a language to write systems
kernels in. I saw an amusing post recently relating to Dan Larimer's work
on EOS mentioning an automated code correctness checking application for
C++... Having intimately dealt with Dan's C++ source code, I can see why he
might be waking up to this, especially with the ether leaks going on, that
EOS has inherited (literally, I presume).
This would not happen if it were written in Go. Note also that Geth lacks
this problem and there was almost going to be a split over code changes
from the Go side.
Linus Torvalds famously said he wrote the Git CVS in C specifically to
exclude C++ programmers. But as any avid gopher would know, C has all kinds
of gotchas to do with busting out of stacks, heaps, allocated memory, and
forgetting to free memory. This does not happen in Go.
So to cut a long story short, this is why I choose to program in Go. I have
a background in low level programming, I used to do a bit of M68k assembler
on my amiga when I was a teenager. I don't mind verbosity that is necessary
due to hardware architectural constraints. And as to the potential users of
my code, I am not responsible for them having a lack of awareness of the
exposed inner workings and them scratching their head at panics when they
try to push the wrong type of value into one of the functions I wrote. They
probably need to do some more study.
I think of programming a bit like carpentry. Sure, you can just whack
together an Ikea table in half an hour, but if you want to make a nice one
that will last hundreds of years, you probably will need to at least spend
a week or two practicing before you even have something simply crude and
functional. C++ and other OOP and interpreted language users are like Ikea
customers. Gophers are like people who go to the sawmill and the specialist
tool store. Disregarding the zero cost of reproduction of course (that's
what Ikea does).
On Friday, 4 May 2018 11:36:33 UTC+3, M P r a d e s wrote:
>
> > Eliminating code duplication shrinks the base of code that must be
> changed
>
> Except go was designed a certain way that will make whatever you are
> attempting to do here burdensome. We've all been there at first trying to
> fit a square into a round hole, it doesn't work. Unless you start ignoring
> Go type system with interface {} everywhere, you're not going to go far
> trying to emulate method overloading in Go. The price of using Go is
> absolutely code duplication and a certain amount of verbosity in order to
> remain type safe. The only real way to achieve method polymorphism in go is
> to use interfaces, since Go supports neither inheritance nor generic
> programming. Go does not allow developers to write "clever" code without
> sacrificing readability or compile time type safety.
>
> Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>>
>> The specifics of how it is done is not as important as why to do it:
>>
>> I am writing this for a later project. It will need at least 5 different,
>> sometimes nearly not very different, short data types. They all have the
>> property of being comparable. The code that keeps them stored and sorted
>> does not need to know anything other than this comparability, and to be
>> able to pass the data back to the caller.
>>
>> I am not making claims about something, trying to sell some snake oil, I
>> am attempting to solve a problem and make use of low level architecture of
>> the hardware to improve performance. It worked for B-heaps so maybe MAYBE
>> it will also benefit binary trees. The way some people respond you'd think
>> I was running an ICO!
>>
>> Programming is usually 5% writing and 95% debugging. Eliminating code
>> duplication shrinks the base of code that must be changed, otherwise I have
>> to delve into code generators or macros. If I have an intended use for a
>> library I am writing, that would require 5 different source files for each
>> data type, yet 90% of the code was the same, what happens when I realise I
>> made a mistake in this common code?
>>
>> I pretty much concluded that it is better to just pass an 8 element
>> function pointer struct as value anyway. Whether the compiler does it
>> differently doesn't really matter since I can't control that. What matters
>> to me is that it's readable so I don't have to spend more time reading than
>> understanding.
>>
>> On Thursday, 3 May 2018 23:40:07 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy <[email protected]>
>>> wrote:
>>>
>>> > As some here may know, I am implementing a novel binary tree based on
>>> complete trees and using ideas from B-heaps in order to achieve maximum
>>> data cache locality in a search and sort algorithm.
>>>
>>> ...
>>>
>>> > Note that this is not really at all an OOP paradigm that I am trying
>>> to ape with this.
>>>
>>> ...
>>>
>>> > I have the base type that concerns itself with the walk, search,
>>> insert and delete functions in an interface.
>>>
>>> ....
>>>
>>> > The b.Overloads - I am not sure, whether it should be pass by value or
>>> pass by reference. I think pass by reference adds an extra resolution step,
>>> but it is probably more expensive as every call of the functions will have
>>> to perform this dereference.
>>>
>>> ...
>>>
>>> > Thanks in advance for any feedback on this.
>>>
>>> - Novelty is only valid when established by peer review. Self-claimed
>>> novelty often means just lack of research. Even if eventually correct, it's
>>> a warning sign for me meanwhile.
>>>
>>> - Attempts to make non-interface types in Go behave in the OOP-style
>>> inheritance is usually a telling sign of using the wrong language - or
>>> abusing one - to solve the problem.
>>>
>>> - Pass by reference has not even a well defined meaning in Go.
>>>
>>> No insult intended, you've explicitly asked for _any_ feedback. My
>>> apologies if you feel offended anyway,
>>>
>>>
>>> --
>>>
>>> -j
>>>
>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
