If I was unclear...I do not mean that Go is the ultimate answer to those questions, or that D (or whatever) is the anthesis of them. I wish Go was different in various ways too.
On Wed, Aug 2, 2017 at 8:39 AM, <eric.pel...@gmail.com> wrote: > I'm still not convinced that using a language which is especially limited > by design always helps in implementing the simplest solution, that will be > the easiest to maintain. > > Maybe it's the case most of the time, but from my personal experience, you > can only get that result by using the right tool for the right job. > > And by "right" I mean the simplest tool which gets you the right result. > > Fortunately, that doesn't happen all the time, but sometimes Go doesn't > give gou that simplest tool, and in that case I severely regret I wasn't > trusted enough so that they let me choose that appropriate tool. > > Le mercredi 2 août 2017 15:26:09 UTC+1, Michael Jones a écrit : >> >> I've often found it helpful to consider extreme limit cases. >> >> In solo/school/hobby programming, you code and test more than you debug >> and you understand intent implicitly because you are coding it as you go. >> As a professional at work, as part of a team, in a code review regime, >> using third-party libraries, evolving large systems, the time distribution >> between coding, testing, debugging, and understanding are different. What >> is the limit case? >> >> The (hypothetical) limit would be no coding and all testing, debugging, >> and understanding. Make it theatrical--the meteor will destroy the Earth >> unless you alone can find the bugs in the billion-line space shield >> software system during the next few days or hours. Now, in such a case, >> think what language and ecosystem features might be helpful. Which are >> neutral? Which might hurt? >> >> I have my own answers, but I raise this to encourage to consider the >> question for themselves. If you do, I expect that you'll see matters at >> issue from a different point of view, from a new perspective that will >> bring a different concept of value. Even though the situation is rather >> extreme, it has much in common with most programming in the large. >> >> On Wed, Aug 2, 2017 at 3:43 AM Egon <egon...@gmail.com> wrote: >> >>> Yes, I would agree -- the type declarations won't bother you in >>> real-world, because when they become unreadable, then you would use >>> additional types to clarify them... in any language. >>> >>> *And, I have nothing against either languages -- I used D in my BSc >>> thesis and Go in my MSc thesis.* >>> >>> The main difference, as I see, is that Go is much more restricted, which >>> means you have to work harder to fit your code into that model, leading to >>> better structures overall. Over time you will learn the simpler ways of >>> structuring your code. With D you have a tons of flexibility, which means >>> often your first idea, what to write, succeeds -- which means the design >>> will be less polished. Also this means that you won't tacitly learn to >>> simplify your code. >>> >>> Yes, you can also write as simple code in D as in Go; the caveat is that >>> Go forces you more into that direction... at the cost of flexibility of the >>> language. So you can write more complex and complected code in D -- for >>> better and worse. >>> >>> + Egon >>> >>> On Wednesday, 2 August 2017 13:25:06 UTC+3, ecstati...@gmail.com wrote: >>>> >>>> Ok I understand you now. Maybe I'm biased because I like both >>>> languages, but I'm not convinced that this example illustrates well Go's >>>> simplicity compared to D. >>>> >>>> For 99% of my *personal* daily use of both languages, very honestly, >>>> I've never felt that using types, functions, arrays, etc etc was simpler in >>>> Go compared to D. >>>> >>>> Even for more complex stuff like concurrency, I think that both >>>> languages still remain quite close, despite I think that Go's channel >>>> system is the best approach to the problem. >>>> >>>> On Wednesday, August 2, 2017 at 10:33:03 AM UTC+1, Egon wrote: >>>>> >>>>> The example contained 3 versions, C, D and Go. >>>>> >>>>> function pointer tables aren't that uncommon, maybe the []error part >>>>> is uncommon >>>>> >>>>> Examples from real world code: >>>>> >>>>> https://github.com/egonelbre/fedwiki/blob/master/action.go#L59 >>>>> https://github.com/ethereum/go-ethereum/blob/master/crypto/ >>>>> sha3/sha3_test.go#L40 >>>>> https://github.com/jteeuwen/go-bindata/blob/master/testdata/ >>>>> out/compress-memcopy.go#L205 >>>>> https://github.com/golang/net/blob/master/proxy/proxy.go#L57 >>>>> https://github.com/golang/go/blob/master/src/cmd/vet/main.go#L150 >>>>> https://github.com/golang/go/blob/master/src/net/http/server.go#L2391 >>>>> https://github.com/golang/go/blob/master/src/cmd/compile/main.go#L23 >>>>> >>>>> And I've used it in Go, Java, C#, JavaScript, Delphi, C... >>>>> >>>>> The main reason you don't see these one-liners often in C, D et. al. >>>>> is because they are hard to read. >>>>> >>>>> For common C, C++ examples, see signal and interrupt vector tables. >>>>> >>>>> On Wednesday, 2 August 2017 12:05:43 UTC+3, ecstati...@gmail.com >>>>> wrote: >>>>>> >>>>>> Still waiting the Go version of this very useful D code... >>>>>> >>>>>> I'm not asking you to browse the web to find to find most complex >>>>>> declaration you can ever do in D, Go or C++ for instance. >>>>>> >>>>>> I've never used such ridiculous code in my Go/D/C++/Java/C# >>>>>> applications, and neither will you. >>>>>> >>>>>> I'm just asking you show me how *simple* code in Go will become much >>>>>> more complicated in D, as this is what you seem to think. >>>>>> >>>>>> And I mean something we will all use all day long (ex: declaring or >>>>>> using functions/types/arrays/slices/references/loops/etc etc), not >>>>>> the most complicated code you can come up with. >>>>>> >>>>>> THAT would be useful, and also a fair comparison between both >>>>>> languages. >>>>>> >>>>>> Because from what I see below, I may think you couldn't manage to >>>>>> find such an example >>>>>> >>>>>> But maybe I'm wrong, I don't know... >>>>>> >>>>>> On Wednesday, August 2, 2017 at 9:33:48 AM UTC+1, Egon wrote: >>>>>>> >>>>>>> On Wednesday, 2 August 2017 10:51:43 UTC+3, ecstati...@gmail.com >>>>>>> wrote: >>>>>>>> >>>>>>>> For all the common parts with Go (functions, methods, reference >>>>>>>> classes, strings, arrays, slices, ranges, foreach, etc), honestly I >>>>>>>> don't >>>>>>>> know why you say it's simpler in Go. >>>>>>>> >>>>>>>> Can you show me two examples of code side by side, and tell me >>>>>>>> "look how much simpler it's with Go's" ? >>>>>>>> >>>>>>>> Because from what I read, I'm sometimes wondering if you really >>>>>>>> know that the type declarations in D are MUCH simpler than in C/C++. >>>>>>>> >>>>>>> >>>>>>> error* (**callbacks)(int); >>>>>>> >>>>>>> Error[] function(int)[][string] callbacks; >>>>>>> >>>>>>> var callbacks map[string]func(int) []error >>>>>>> >>>>>>> >>>>>>>> For instance : >>>>>>>> >>>>>>>> int[] >>>>>>>> first_array_of_ints, >>>>>>>> second_array_of_ints; >>>>>>>> >>>>>>>> int[string] >>>>>>>> first_map_of_ints_indexed_by_a_string, >>>>>>>> second_map_of_ints_indexed_by_a_string; >>>>>>>> >>>>>>>> TYPE >>>>>>>> first_reference_to_an_object_of_this_type, >>>>>>>> second_reference_to_an_object_of_this_type; >>>>>>>> >>>>>>>> So, with all due respect, how many applications have you already >>>>>>>> programmed in D before telling me that Go's syntax is so simpler to >>>>>>>> use and >>>>>>>> to learn ? >>>>>>>> >>>>>>>> I agree there are much *less* possibilities in Go, but that >>>>>>>> doesn't mean it's automatically a simpler language to learn for all the >>>>>>>> common parts with D. Seriously. >>>>>>>> >>>>>>>> Because I had to learn both, and at least for a C++/Java/C# >>>>>>>> programmer like me, D transition was almost immediate, really a matter >>>>>>>> of >>>>>>>> hours to become comfortable with the language. Everything was alike, >>>>>>>> but >>>>>>>> much simpler and easier than in C++. >>>>>>>> >>>>>>>> Believe me or not, I've taught programming with D to my two >>>>>>>> teenagers with D. Really. >>>>>>>> >>>>>>>> I've chosen it because it was the only strongly-typed language >>>>>>>> close to Javascript that was really easy to learn, while allowing them >>>>>>>> to >>>>>>>> quickly switch to C++, Java or C# later if they wanted to. >>>>>>>> >>>>>>>> Go is much simpler than C++ too, I agree of course, but for having >>>>>>>> learned both Go then D, again from the point of view of a former >>>>>>>> C++/Java/C# programmer like me, I didn't feel that quickly at home >>>>>>>> with Go >>>>>>>> than with D, mainly because Go diverged much more from its predecessors >>>>>>>> than D from a syntactic point of view. >>>>>>>> >>>>>>>> So, again from a syntactic point of view, I don't think how you can >>>>>>>> affirm that it's much easier in Go than in D to declare and use types, >>>>>>>> references, functions, methods, slices, arrays, foreach, and all the >>>>>>>> common >>>>>>>> stuff between both languages. >>>>>>>> >>>>>>>> Honestly, no offense intended. >>>>>>>> >>>>>>>> On Tuesday, August 1, 2017 at 10:11:10 PM UTC+1, Doğan Kurt wrote: >>>>>>>>> >>>>>>>>> But from my personal experience, D is *at least* as easy to learn >>>>>>>>>> than Go, if not easier. >>>>>>>>> >>>>>>>>> >>>>>>>>> I seriously doubt, no offense. Go is so small and so intuitive, >>>>>>>>> one can argue that there are people out there who knows most of the Go >>>>>>>>> unknowingly :) >>>>>>>>> >>>>>>>>> Just the fact that it doesn't break much with the familiar syntax >>>>>>>>>> of C#, Java, C++, etc helps a lot in making the transition. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Go's syntax is very familiar to C, i've never heard it was an >>>>>>>>> issue. The only think you must get used to is declarations and i LOVE >>>>>>>>> the >>>>>>>>> Go way. I remember the days i was struggling with C's declaration >>>>>>>>> model, >>>>>>>>> the spiral rule etc. sure we use typedefs but it rather feels like a >>>>>>>>> hack. >>>>>>>>> I can write any declaration no matter how complex it is, with my >>>>>>>>> eyes closed in Go. It's so great. >>>>>>>>> >>>>>>>>> And genericity and polymorphism are invaluable tools when >>>>>>>>>> optimizing code reuse without reducing execution speed. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I don't ever remember duplicating any code in C. I can't >>>>>>>>> understand how people are unable to write reusable code with C, >>>>>>>>> seriously. >>>>>>>>> Whenever i discuss this with a C++ programmer, they immediately share >>>>>>>>> some >>>>>>>>> generic Max function that works with int and double. I admit i use >>>>>>>>> macros >>>>>>>>> in that case, but come on it's not even 1% of the serious programming >>>>>>>>> you >>>>>>>>> do in C. >>>>>>>>> >>>>>>>>> If you are a competent C programmer (structured programming in >>>>>>>>> general), you know how to write reusable code. >>>>>>>>> >>>>>>>> -- >>> 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. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Michael T. Jones >> michae...@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. > -- Michael T. Jones 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.
