Well after bashing my head against a brick wall I finally understand what a
mess it is for my specific purpose to work with Go. Nobody really
specifically said it in any discussions up to now but what my design needs
is generics. If code generation could be done more transparently I could
use that but it really kicks interactivity and flow in the nuts. I'm going
to probably abandon Golang on this basis. I am inclined to go with C but I
am nervous about issues relating to pointers and runtime breaks but oh
well. </discussion for me>.
If there was a way to transparently add code generation that would be
sufficient and remain type safe. *sigh*
The biggest headache I am running up against is that between packages. I
think that before I throw in the towel I am going to study exactly how the
sort package is implemented, since in essence my library does the same
thing, so maybe I just don't understand well enough how to use interfaces,
embedding and composition.
On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>
> 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 <
>>>> louki.sumir...@gmail.com> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
