4 ms·

#2 maybe, #7 for sure... But the rest are either (A) it doesn't work the way I want it to work or (B) I haven't read the manual and it's your fault.

by pawadu 10y ago

passiveincomelg 10y ago
What about #1? I have only written small amounts of Go code so far. But even then I was often wondering how to name variables. Part of it was coming back to static typing after writing lots of Python, but I'm pretty sure I ran into this issue quite a bit as well.
coldtea 10y ago
Aside from 2 and 7, also 8, 4, 3, 10, 11 are all awful, and they can't be written down as "personal preference" or "RTFM". It's 2016, Generics are not some controversial "personal preference" and neither are badly designed APIs.
- pawadu 10y ago
  Are generics really a requirement for a 2016 programming language? Take a look at the TIOBE index, how many of the top 50 languages have _proper_ generics support? http://www.tiobe.com/tiobe-index/ http://www.tiobe.com/tiobe-index/ edit: not saying generics are bad, but not having generics in golang was a design decision not an oversight.
  - coldtea 10y ago
    >Are generics really a requirement for a 2016 programming language? Take a look at the TIOBE index, how many of the top 50 languages have _proper_ generics support? How many of them are 2016 programming languages, solving 2016 problems -- as opposed to 2 and 3 and 5 decades old languages designed in another era? (Not to mention that even some 3+ decades old languages have generics...) >edit: not saying generics are bad, but not having generics in golang was a design decision not an oversight. I think in some languages design decisions and oversights are not contradictory.
    - pawadu 10y ago
      I guess the point I wanted to make was that having proper generics in a language is very hard and whats why very few languages attempt to implement it. And people are still arguing whether generics in C++ do more harm than good (i.e. complicate debugging). So not supporting generics is a design decision and not always a bad one.
      - coldtea 10y ago
        >I guess the point I wanted to make was that having proper generics in a language is very hard and whats why very few languages attempt to implement it. I'm not sure about this, I believe it's a solved problem. Languages have had them for decades, and lots of different avenues have been explored. Neither Java nor C# (and those are mainstream pragmatic languages, not experimental academic affairs) have particular issues with their (different) respective Generics implementations (except the obvious tradeoffs I mean -- but it's not like programmers or their compiler writers are strugging because of them in any way). They are also quite easy to add to a language (even hobbyist languages have them) -- I'm not sure why you say that "very few languages attempt to implement it". The big two used by tens of millions (Java and C#) have them, C++ has them, F# has them, Swift has them, Scala has them, Delphi had them, lesser used languages like Ada, Julia, Haskell, D etc have them. Heck, almost all modern mainstream languages have them. "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even include the compiler being harder to write. Yeah, I don't think they can magically created pain free either. I do think they solve a lot of pain where it matters: for the programmers. >And people are still arguing whether generics in C++ do more harm than good (i.e. complicate debugging). That's because generics in C++ come with all the template baggage and a full turing-complete and complicated scheme to work with them. There's no need to go there.
        codygman 10y ago
        > "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even include the compiler being harder to write. This. To further add to this, an argument against generics used to be worries about showing compile times, but that didn't stop rewriting the compiler in Go or implementing SSA. Go's compile times are still much slower than they were. Point being that generics aren't seen as important, not as being too difficult to implement correctly.
junke 10y ago
#3 (too easy to ignore errors) and #6 (hard code generation) do not seem to be either A or B.
- pawadu 10y ago
  regarding #3, have you never seen code like this? try { stuff() } exception(Exception e) { } I would consider complaint #6 a B.
  - junke 10y ago
    This has nothing to do with the matter at hand. Explicitly ignoring errors is a feature that you sometimes need. The equivalent in Go would be to write: _ := db.Exec("DELTE FROM item WHERE id = 2") ... which could be written for bad reasons too, like in Java. However, nothing prevents from writing: db.Exec("DELTE FROM item WHERE id = 2") ... which would be like: stuff() Both of those could be written either intentionally or by error, maybe because someone did not read the documentation correctly. However with exceptions, even if the exception is not handled, at least it is caught. So Go by design does not use exceptions, which is respectable choice. However, it is supposed to be different from C by making it hard to ignore errors. And the example from #3 is the absolute contradiction of that philosophy. I'd expect all return values to be checked for usage. Go could take example from Ada in that regard. ----- For #6, what would be the solutions to OP's example problems?
    - pawadu 10y ago
      Hmmm, you are correct, it is easy to ignore these types of errors. I guess I should have read the article more carefully

#2 maybe, #7 for sure... But the rest are either (A) it doesn't work the way I want it to work or (B) I haven't read the manual and it's your fault.

by pawadu 10y ago

#2 maybe, #7 for sure... But the rest are either (A) it doesn't work the way I want it to work or (B) I haven't read the manual and it's your fault.

passiveincomelg 10y ago

What about #1? I have only written small amounts of Go code so far. But even then I was often wondering how to name variables. Part of it was coming back to static typing after writing lots of Python, but I'm pretty sure I ran into this issue quite a bit as well.

coldtea 10y ago

Aside from 2 and 7, also 8, 4, 3, 10, 11 are all awful, and they can't be written down as "personal preference" or "RTFM". It's 2016, Generics are not some controversial "personal preference" and neither are badly designed APIs.

pawadu 10y ago
Are generics really a requirement for a 2016 programming language? Take a look at the TIOBE index, how many of the top 50 languages have _proper_ generics support? http://www.tiobe.com/tiobe-index/ http://www.tiobe.com/tiobe-index/ edit: not saying generics are bad, but not having generics in golang was a design decision not an oversight.
- coldtea 10y ago
  >Are generics really a requirement for a 2016 programming language? Take a look at the TIOBE index, how many of the top 50 languages have _proper_ generics support? How many of them are 2016 programming languages, solving 2016 problems -- as opposed to 2 and 3 and 5 decades old languages designed in another era? (Not to mention that even some 3+ decades old languages have generics...) >edit: not saying generics are bad, but not having generics in golang was a design decision not an oversight. I think in some languages design decisions and oversights are not contradictory.
  - pawadu 10y ago
    I guess the point I wanted to make was that having proper generics in a language is very hard and whats why very few languages attempt to implement it. And people are still arguing whether generics in C++ do more harm than good (i.e. complicate debugging). So not supporting generics is a design decision and not always a bad one.
    - coldtea 10y ago
      >I guess the point I wanted to make was that having proper generics in a language is very hard and whats why very few languages attempt to implement it. I'm not sure about this, I believe it's a solved problem. Languages have had them for decades, and lots of different avenues have been explored. Neither Java nor C# (and those are mainstream pragmatic languages, not experimental academic affairs) have particular issues with their (different) respective Generics implementations (except the obvious tradeoffs I mean -- but it's not like programmers or their compiler writers are strugging because of them in any way). They are also quite easy to add to a language (even hobbyist languages have them) -- I'm not sure why you say that "very few languages attempt to implement it". The big two used by tens of millions (Java and C#) have them, C++ has them, F# has them, Swift has them, Scala has them, Delphi had them, lesser used languages like Ada, Julia, Haskell, D etc have them. Heck, almost all modern mainstream languages have them. "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even include the compiler being harder to write. Yeah, I don't think they can magically created pain free either. I do think they solve a lot of pain where it matters: for the programmers. >And people are still arguing whether generics in C++ do more harm than good (i.e. complicate debugging). That's because generics in C++ come with all the template baggage and a full turing-complete and complicated scheme to work with them. There's no need to go there.
      - codygman 10y ago
        > "Proper generics" is a red herring put forth by Pike, where its would only be OK to have generics if it came without any tradeoff at all, where tradeoffs even include the compiler being harder to write. This. To further add to this, an argument against generics used to be worries about showing compile times, but that didn't stop rewriting the compiler in Go or implementing SSA. Go's compile times are still much slower than they were. Point being that generics aren't seen as important, not as being too difficult to implement correctly.

junke 10y ago

#3 (too easy to ignore errors) and #6 (hard code generation) do not seem to be either A or B.

pawadu 10y ago
regarding #3, have you never seen code like this? try { stuff() } exception(Exception e) { } I would consider complaint #6 a B.
- junke 10y ago
  This has nothing to do with the matter at hand. Explicitly ignoring errors is a feature that you sometimes need. The equivalent in Go would be to write: _ := db.Exec("DELTE FROM item WHERE id = 2") ... which could be written for bad reasons too, like in Java. However, nothing prevents from writing: db.Exec("DELTE FROM item WHERE id = 2") ... which would be like: stuff() Both of those could be written either intentionally or by error, maybe because someone did not read the documentation correctly. However with exceptions, even if the exception is not handled, at least it is caught. So Go by design does not use exceptions, which is respectable choice. However, it is supposed to be different from C by making it hard to ignore errors. And the example from #3 is the absolute contradiction of that philosophy. I'd expect all return values to be checked for usage. Go could take example from Ada in that regard. ----- For #6, what would be the solutions to OP's example problems?
  - pawadu 10y ago
    Hmmm, you are correct, it is easy to ignore these types of errors. I guess I should have read the article more carefully