3 ms·

> I mean comments like "Also my hair gets paler and my body grows weak thinking about using defer with named return values" are borderline silly. I regret my d

> I mean comments like "Also my hair gets paler and my body grows weak thinking about using defer with named return values" are borderline silly. I regret my deliberate silliness only reaches "borderline" with you. Do I also need a unicycle. What does it take?! > StrToBool Make this function 30 lines long, take 6 arguments and then you have my original argument. It creates context sensitivity, something Golang tries not to do. > But most of the code I write and collaborate with is more around 20 lines or less. I'm tempted to write a github crawler to work this out. Golang is C-like in that its lack of reuse capabilities incentivize longer functions or copypaste functions. I'm simply against this kind of context-sensitivity in a language that prides itself on being reader friendly. It's not. Let me rephrase my argument. Question: return a; // What does this do? Response: It returns the value at a. I don't know what that value is, but it must be a local or a function parameter. This function definitely returns a value, one value. Question 2: return; // What does THIS do? Response: Well... all I can say with confidence is that this returns, the functions execution will end. But I can't tell you if it returns nothing, or a value, or how many values. The existence of this makes bare returns much more confusing than... well... I struggle to come up with a syntactical convention in Golang that can do this. I haven't written Go for reals for 2 years so maybe you have something better. To me, this is way worse than even the "worst case" Haskell scenarios where your code only makes sense in the context of its caller.

laumars 9y ago
> Make this function 30 lines long, take 6 arguments and then you have my original argument. It creates context sensitivity, something Golang tries not to do. But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. It's like the whole goto statement argument. Nobody is suggesting we all using goto's just because the feature exists. But very occasionally it does produce cleaner code. Yet you still get an army of evangelists who argue that "goto" should be stripped from every language specification written since the 80s. I've read a lot of other people's code. Particularly the Go source code itself - there's named returns all over the place there. There are also some quite long and complicated functions too. The use of a named return has had a negligible impact on my ability to parse a function compared to any of the other inherent complexities that function exhibited. ie I followed that code just as easily than if those returns were not named. Which is why I keep coming back to the "You're points are not wrong per se but they are greatly exaggerated." arguement. But like nearly all arguments about language semantics and syntax, developers love to argue how their personal preferences are conclusive scientific facts. Ironically spending more time trying to prove our points online than we actually spend affected by the problems we're arguing about. So yes, you are not wrong per se. But you are greatly exaggerating the issue.
- KirinDave 9y ago
  > But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. There's a 30 line function claimed to be a refactor of production code in the article we are discussing. It's not my whole cloth example. Heck, my first post was commenting on the structure of that very function hoping it was a defactoring example. People have chosen to focus on the other point in that post. > So yes, you are not wrong per se. But you are greatly exaggerating the issue. I understand what you're trying to do but I'm pointing to the overarching article. I didn't make this scenario up. Also, the personal context I bring here is how many lectures I get from anti-haskell-pro-Go people lecturing me about simplicity, obviousness, etc ad nauseum about why I should adopt their language. So if you're detecting a bit of frustration here at a double standard, I do apologize.
  - laumars 9y ago
    Yeah, the article wasn't great. I think few supporters of named returns would even agree with that article. Like all language features, you're always going to get some individuals who will misuse them. The author there I definitely think is misusing named returns for something that really needs to be optimised in the compiler instead.
    - KirinDave 9y ago
      In defense of the article, I can see how anyone writing a lot of Go would start to get a bit desperate for shortcuts. It's a language that's relentlessly hard on prolific writers, putting their needs second in favor of minimizing the context required for any code. So I could see how things like having a alternative-providing validator chain take 5% fewer characters would feel intoxicating after using code generation to stamp out four variants of a competent data structure for some primitive types.
      - laumars 9y ago
        One minute you're moaning that features need to be removed from Go, the next you're mocking it for not having enough features. Yet you dont even code in the language you're clearly very opinionated and highly critical over. We all have our personal preferences, I get that. But why can't people just live and let live instead of trying to make out their personal preferences are measurably better than those they dislike? After all, if all programming languages were identical then the IT industry would be worse off for it. For what it's worth, I've been writing software for nearly 3 decades now and have writing applications in well over a dozen different languages. Go might lack some of the expressiveness I'm used to but it's still one of the most rapid languages I've used to create software. And one of the most painless to deploy too. In fact ironically some of the "worst languages" in terms of developer chin stroking have been some of the easiest to work with; Visual Basic (pre .NET) is another example. But if I had my way we would be back to writing DOS programs in Turbo Pascal. This is why I get so fed up with people moaning about their tools. Frankly put, mocking any particular tool for not behaving like another particular tool just shows ones own limitation as a developer.

laumars 9y ago

> Make this function 30 lines long, take 6 arguments and then you have my original argument. It creates context sensitivity, something Golang tries not to do. But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. It's like the whole goto statement argument. Nobody is suggesting we all using goto's just because the feature exists. But very occasionally it does produce cleaner code. Yet you still get an army of evangelists who argue that "goto" should be stripped from every language specification written since the 80s. I've read a lot of other people's code. Particularly the Go source code itself - there's named returns all over the place there. There are also some quite long and complicated functions too. The use of a named return has had a negligible impact on my ability to parse a function compared to any of the other inherent complexities that function exhibited. ie I followed that code just as easily than if those returns were not named. Which is why I keep coming back to the "You're points are not wrong per se but they are greatly exaggerated." arguement. But like nearly all arguments about language semantics and syntax, developers love to argue how their personal preferences are conclusive scientific facts. Ironically spending more time trying to prove our points online than we actually spend affected by the problems we're arguing about. So yes, you are not wrong per se. But you are greatly exaggerating the issue.

KirinDave 9y ago
> But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations. There's a 30 line function claimed to be a refactor of production code in the article we are discussing. It's not my whole cloth example. Heck, my first post was commenting on the structure of that very function hoping it was a defactoring example. People have chosen to focus on the other point in that post. > So yes, you are not wrong per se. But you are greatly exaggerating the issue. I understand what you're trying to do but I'm pointing to the overarching article. I didn't make this scenario up. Also, the personal context I bring here is how many lectures I get from anti-haskell-pro-Go people lecturing me about simplicity, obviousness, etc ad nauseum about why I should adopt their language. So if you're detecting a bit of frustration here at a double standard, I do apologize.
- laumars 9y ago
  Yeah, the article wasn't great. I think few supporters of named returns would even agree with that article. Like all language features, you're always going to get some individuals who will misuse them. The author there I definitely think is misusing named returns for something that really needs to be optimised in the compiler instead.
  - KirinDave 9y ago
    In defense of the article, I can see how anyone writing a lot of Go would start to get a bit desperate for shortcuts. It's a language that's relentlessly hard on prolific writers, putting their needs second in favor of minimizing the context required for any code. So I could see how things like having a alternative-providing validator chain take 5% fewer characters would feel intoxicating after using code generation to stamp out four variants of a competent data structure for some primitive types.
    - laumars 9y ago
      One minute you're moaning that features need to be removed from Go, the next you're mocking it for not having enough features. Yet you dont even code in the language you're clearly very opinionated and highly critical over. We all have our personal preferences, I get that. But why can't people just live and let live instead of trying to make out their personal preferences are measurably better than those they dislike? After all, if all programming languages were identical then the IT industry would be worse off for it. For what it's worth, I've been writing software for nearly 3 decades now and have writing applications in well over a dozen different languages. Go might lack some of the expressiveness I'm used to but it's still one of the most rapid languages I've used to create software. And one of the most painless to deploy too. In fact ironically some of the "worst languages" in terms of developer chin stroking have been some of the easiest to work with; Visual Basic (pre .NET) is another example. But if I had my way we would be back to writing DOS programs in Turbo Pascal. This is why I get so fed up with people moaning about their tools. Frankly put, mocking any particular tool for not behaving like another particular tool just shows ones own limitation as a developer.