5 ms·

Complex language features have much more of a toll on reading code than they have on writing code. One example that I like to use is that while Go's lack of ope

• VBprogrammer 3y ago
  > Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" It's funny, in 10 years of writing Python professionally I can only think of one occasion when I had to dig into what a __add__ operation did (a Money library which didn't special case 0 meaning sum didn't work as you might hope). I think it's probably because python has a pretty comprehensive standard library which gives reasonably consistent examples of where to use them.
• merb 3y ago
  That is not necessarily true. Especially the error handling makes it really awkward to read go code. A lot of languages with an expressive type system do look aweful when looking at methods. But the same thing can be done with go methods. Writing hard to understand go code is just as easy as say with scala or rust
  • sakjur 3y ago
    Oh, absolutely. I don't mean to claim Go as an outstanding example of a well-designed programming language. I appreciate Go's language design, but I also similarly appreciate Scala, Rust, Java, Erlang and various other programming languages I've interacted with. My point is more against the notion that AI assistants would make careful language design any less important than in favor of any particular language. The popular programming languages all have their own virtues and drawbacks (and the unpopular ones almost certainly have at least their own drawbacks).
  • randomdata 3y ago
    > Especially the error handling makes it really awkward to read go code. Go does not have error handling at all, just general value handing. What do you find awkward about its value handlers? They are essentially the same as every other C-style language out there.
    • VBprogrammer 3y ago
      It's certainly not difficult to understand Go error handling. But it does take up quite a bit of real-estate. I think more importantly for me, it's too easy to forget an error check. Having primitives which make error checking painless and validated by the compiler would be nice.
      • usrbinbash 3y ago
        > it's too easy to forget an error check. How? What exactly makes this "too easy"? In regards to a functions error returns, there are exactly two things a caller can do func foo() (int, error) { // foo code } // explicitely ignore the error foo() val, _ := foo() // handling the error val, err := foo() _, err := foo() If I do the latter, I cannot ignore `err`. If I do, the compiler yells at me because there is now an unused value in my code. If I do the former, then I made the conscious choice that the error doesn't matter to me. Yes, this goes for `foo()` as well, because Go makes it exceedingly clear that errors are just return values, and that call ignores all returns.
        • VBprogrammer 3y ago
          Unless things have changed, if the return is only a single error value then it's possible to overlook capturing it.
      • randomdata 3y ago
        > it's too easy to forget an error check. I never understood this. I do understand it is easy to forget to handle an error like it is easy to forget to handle a distance or temperature. Humans will make mistakes. But nobody laments about how they forget to handle distances or temperatures, or cry for special constructs to ensure that they don't screw up their distance and temperature handling. What is it about the word error that sends developers into a tizzy? Why would we want a solution that only works for errors and not for values of all kinds?
• mejutoco 3y ago
  I think you will like this quote :) "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan I dont know if it applies to language features, though.
• xigoi 3y ago
  > it means that you'll never have to dig deep to understand what "+" is doing on this particular line, Instead you'll have to dig deep to undershnnd what "Add()" is doing on this particular line. How is that any different?
  • thunky 3y ago
    Because parent is taking about operators like "+" and how it can be confusing not knowing if a function call is behind it. This is different from obvious functions like "Add()".
    • xigoi 3y ago
      How is “Add()” any different from “+”? They're just two different names for the same thing – a function that adds two numbers or other objects.
      • usrbinbash 3y ago
        > They're just two different names for the same thing No, they are not. One is a function, the other is an operator. An operator has implicit meaning. I know with absolute certainty, that `+` is supposed to mean that 2 things are added to one another. `Add()` is a function. Its name may or may not indicate what it is actually doing. Even if it indicates it, it may not be obvious how it is doing it's thing, or how good the indication is. Example: If Add takes as first argument a list and as second argument an integer, does it append the integer to the list? Does it add it to every element of the list? Does it sum the list and add the integer to the result? All these things could be meant by "Add"-ing an integer to the list. Does it have side effects? I don't know, and I don't expect to know, until I look at `Add()` (or at least read it's documentation). That is the big difference between operators and functions; With operators, I expect to know what it does, without looking it up. And that's also the big problem with operator-overloading, because as soon as a language supports that, that assumption flies out the window.
      • thunky 3y ago
        Because if the language doesn't allow overloading (which is the context of this thread) then "+" will always be implemented by the language. That's a big difference.