| > Wow, if that's voice typing, I'm impressed, mine is never that good :) I had to correct a few things, but I was pretty impressed by the accuracy :D > I do understand where you're coming from. More code means more code that can have bugs, I totally agree. Right, I find it easier to use very generic functions and compose them together. Go achieves some of this with interfaces, but my rub with that is that they aren't type safe IIRC. Which my experience has taught me is quite valuable. > However, more complicated code also means more bugs, No arguments here! > and generic code is definitely more complicated and non-generic code (in all but the most simplistic cases). Can we test this right now? Have any examples in mind so we could figure this out in code? > So, I don't think it's necessarily as straight forward as O(n) vs O(1).... I agree, I didn't mean for my statements to be taken as absolutes or perfectly accurate but more as a lens to look through. > and also for small values of n, O(n) is pretty close to O(1)... and my contention is that n is almost always small. I agree here, and this will lead us to the source of our (and many others disagreements). I feel that when as much code is as generic as possible, I can make more generic code and lessen the potential points of failure. Forgive the projection, but I feel your thoughts are more along the lines of "Really generic code isn't simple and simple code is the key to fast, easy to maintain, and well... simple code". I was a big fan of Go in the past and thought along the same lines. I gave Haskell a try and things being very generic didn't seem to make complexity go up much to me. This means it feels like a lot of Go proponents just dismiss Ocaml, Haskell, Scala, Clojure, etc as something convoluted and overly complex from the outside, but having spent some time in getting to know the language it seems just as simple or more simple than Go (although VERY different) in many areas (not deployment (Go does very good here) and I suspect not reasoning about performance but my use cases haven't necessitated enough profiling Haskell code to say for sure). Just a random question, what do you and (if you don't mind guessing a little) other Gophers think of Nim? If I were to pick a dead simple imperative language along the lines of Go that didn't "ignore programming language research" I would pick Nim over Go unless there was a huge deficit in libraries for my use case. |