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 <egonel...@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+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.
