7 ms·

> without realizing it involves a linear search is considered one of the benefits of Go. The primary problem that I think the author was trying to get at is th

> without realizing it involves a linear search is considered one of the benefits of Go. The primary problem that I think the author was trying to get at is that go lacks tools for building abstractions. In a language with generic functions (for instance), it would be possible to implement a delete_at function completely in user code. The fact that you cannot reflects poorly on the language. Of course it will always be possible to write functions that have arbitrarily slow time complexities. That's something you have to be aware of, with any function; it's not a reason to avoid including a linear-time function to remove an element at a given index of an array.

grey-area 6y ago
That’s a deliberate choice in many ways, and it means you don’t end up building castles in the air, or worse, working within someone else’s castle in the air. See the lack of inheritance for a good example of a missing abstraction which improves the language. Abstractions are pretty and distracting but they are not why we write code and each one has a cost, which is often not apparent when introduced. That’s not to say Go is perfect, there are a few little abstractions it would IMO be improved by having and the slice handling in particular could be more elegant and based on extending slice types or a slices package rather than built in generic functions.
- stiray 6y ago
  > and it means you don’t end up building castles in the air, or worse, working within someone else’s castle in the air. See the lack of inheritance for a good example of a missing abstraction which improves the language. Very well said. If only more developers would understand this. Yes I know, creating interfaces, inheriting everything from the void, adding as large amount of layers to create the beautifully constructed reusable structure is a nice drive but it might happen no one will reuse it as doesn't want to dive itself trough infinite level lasagna with rolling ravioli around it (and - thanks god, go doesn't have try/catch - throwing exceptions trough all the layers to force you to go down the guts of the construct to figure out what it means). Or, as it often happens, will be forced to reuse it, complicating his life and is code. I do understand that inheritance, even operator overloading has its meaning and is extremely useful. But it has another side - everybody are overdoing it as "might come handy later" and the code becomes a case for "How to write unmaintainable code"[2]. When I am coding I am not doing it for philosophical reasons and go has until now succeeding being a very helpful tool without much of "meaning of life" complications. And i would love to see it stay that way. If you are forcing me to read the documentation / code (presumably I know what I am trying to solve) to be able to use the "beautiful oo construct" and forcing you to read your beautiful design, you have failed making it and I have seen it in java everywhere. I just hope the same people making everything complicated more than it need to be wont skip from java[1] train to go train. I really don't want them anywhere close. [1]https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... [2]https://github.com/Droogans/unmaintainable-code https://github.com/Droogans/unmaintainable-code (and 20 others)
  - marcus_holmes 6y ago
    Yeah, this. I always found myself creating beautiful OO constructs that were invariably overfitted to my understanding of the state of the problem at that time, and were really hard work to change once I understood the problem better (or it changed).
  - doctor_eval 6y ago
    Yeah I’ve fallen into this trap and worst of all, I’ve had my team fall into it and not find their way out. Abstractions are a great idea, and Go has plenty of these (io.Writer is ubiquitous), but most business logic is dead boring and doesn’t need it.
- kaba0 6y ago
  I don’t see why a well-built standard library would be in the way. In the case of delete, well write your own linear search if you are into, though it gets old imo fast. But will you also write a sort algorithm by hand? Because I am fairly sure it won’t be competitive with a properly written one. Also, what about function composition? Will you write a complicated for loop with ifs and whatnot when a filter, foldl and friends would be much more readable?
  - cube2222 6y ago
    Go actually does contain a sort package in the stdlib: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/ with the most ergonomic function being sort.Slice As for a complicated for loop instead of the functional equivalent: I too am a fan of functional patterns in this case, but the for loop equivalent in my opinion is just as readable in 99% of cases. A little more verbose, that's all. Matter of taste.
  - somehow1 6y ago
    Here is an example, https://www.cryptopp.com/ https://www.cryptopp.com/ , I love this library. Beautifully designed, extremely capable, incredible what you can do in two lines of code. I hate to use it down to my guts. Try to use it and you will understand.
  - grey-area 6y ago
    I agree filtering and many generic operations on slices would be nice, I think they have plans for it once generics lands. I don’t agree they are huge problems though, they are much simpler than sorting algorithms for example (which are included). A range vs a series of filtering operations is an interesting question in terms of which is easiest to write or, crucially, for a beginner to understand after writing - not convinced foldl is easy for beginners. If you like abstractions like that, Go will be abhorrent to you, and that’s ok. It is easy to build your own filter on a specific type, I’ve only done it a couple of times, it is literally no more than a for loop/range. Where I have written extensions and would appreciate helpers in the std lib is things like lists of ints and strings - contains, filter and friends would be welcome there in the stdlib (I use my own at present). For filter etc I think I’d use them but am not convinced they would change the code much - the complexity is in what you do to filter not the filtering operation itself which probably adds about 3 lines and is very simple (set up new list, add to list in range, return list). For example in existing code I have lots of operations on lists of items which sit behind a function and for hardly any of them would I delete the function and just use filter in place at the call site, because I have the function to hide the complexity of the filtering itself (all those if conditions), which would not go away. I wouldn’t even bother rewriting the range to use filter because it’s not much clearer.

grey-area 6y ago

That’s a deliberate choice in many ways, and it means you don’t end up building castles in the air, or worse, working within someone else’s castle in the air. See the lack of inheritance for a good example of a missing abstraction which improves the language. Abstractions are pretty and distracting but they are not why we write code and each one has a cost, which is often not apparent when introduced. That’s not to say Go is perfect, there are a few little abstractions it would IMO be improved by having and the slice handling in particular could be more elegant and based on extending slice types or a slices package rather than built in generic functions.

stiray 6y ago
> and it means you don’t end up building castles in the air, or worse, working within someone else’s castle in the air. See the lack of inheritance for a good example of a missing abstraction which improves the language. Very well said. If only more developers would understand this. Yes I know, creating interfaces, inheriting everything from the void, adding as large amount of layers to create the beautifully constructed reusable structure is a nice drive but it might happen no one will reuse it as doesn't want to dive itself trough infinite level lasagna with rolling ravioli around it (and - thanks god, go doesn't have try/catch - throwing exceptions trough all the layers to force you to go down the guts of the construct to figure out what it means). Or, as it often happens, will be forced to reuse it, complicating his life and is code. I do understand that inheritance, even operator overloading has its meaning and is extremely useful. But it has another side - everybody are overdoing it as "might come handy later" and the code becomes a case for "How to write unmaintainable code"[2]. When I am coding I am not doing it for philosophical reasons and go has until now succeeding being a very helpful tool without much of "meaning of life" complications. And i would love to see it stay that way. If you are forcing me to read the documentation / code (presumably I know what I am trying to solve) to be able to use the "beautiful oo construct" and forcing you to read your beautiful design, you have failed making it and I have seen it in java everywhere. I just hope the same people making everything complicated more than it need to be wont skip from java[1] train to go train. I really don't want them anywhere close. [1]https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... [2]https://github.com/Droogans/unmaintainable-code https://github.com/Droogans/unmaintainable-code (and 20 others)
- marcus_holmes 6y ago
  Yeah, this. I always found myself creating beautiful OO constructs that were invariably overfitted to my understanding of the state of the problem at that time, and were really hard work to change once I understood the problem better (or it changed).
- doctor_eval 6y ago
  Yeah I’ve fallen into this trap and worst of all, I’ve had my team fall into it and not find their way out. Abstractions are a great idea, and Go has plenty of these (io.Writer is ubiquitous), but most business logic is dead boring and doesn’t need it.
kaba0 6y ago
I don’t see why a well-built standard library would be in the way. In the case of delete, well write your own linear search if you are into, though it gets old imo fast. But will you also write a sort algorithm by hand? Because I am fairly sure it won’t be competitive with a properly written one. Also, what about function composition? Will you write a complicated for loop with ifs and whatnot when a filter, foldl and friends would be much more readable?
- cube2222 6y ago
  Go actually does contain a sort package in the stdlib: https://golang.org/pkg/sort/ https://golang.org/pkg/sort/ with the most ergonomic function being sort.Slice As for a complicated for loop instead of the functional equivalent: I too am a fan of functional patterns in this case, but the for loop equivalent in my opinion is just as readable in 99% of cases. A little more verbose, that's all. Matter of taste.
- somehow1 6y ago
  Here is an example, https://www.cryptopp.com/ https://www.cryptopp.com/ , I love this library. Beautifully designed, extremely capable, incredible what you can do in two lines of code. I hate to use it down to my guts. Try to use it and you will understand.
- grey-area 6y ago
  I agree filtering and many generic operations on slices would be nice, I think they have plans for it once generics lands. I don’t agree they are huge problems though, they are much simpler than sorting algorithms for example (which are included). A range vs a series of filtering operations is an interesting question in terms of which is easiest to write or, crucially, for a beginner to understand after writing - not convinced foldl is easy for beginners. If you like abstractions like that, Go will be abhorrent to you, and that’s ok. It is easy to build your own filter on a specific type, I’ve only done it a couple of times, it is literally no more than a for loop/range. Where I have written extensions and would appreciate helpers in the std lib is things like lists of ints and strings - contains, filter and friends would be welcome there in the stdlib (I use my own at present). For filter etc I think I’d use them but am not convinced they would change the code much - the complexity is in what you do to filter not the filtering operation itself which probably adds about 3 lines and is very simple (set up new list, add to list in range, return list). For example in existing code I have lots of operations on lists of items which sit behind a function and for hardly any of them would I delete the function and just use filter in place at the call site, because I have the function to hide the complexity of the filtering itself (all those if conditions), which would not go away. I wouldn’t even bother rewriting the range to use filter because it’s not much clearer.