4 ms·

While I understand your comment, I have to disagree. Programming languages should be kind of boring, and support the average developers' work. That is why Hask

While I understand your comment, I have to disagree. Programming languages should be kind of boring, and support the average developers' work. That is why Haskell will ultimate fail and fade away - most of the developers on this planet are simply not skilled enough to touch any of that stuff. Attempting to add all Ninja concepts to a language will just lead to a massive failure. Go does a very good job on forcing even the most average developers to reach surprisingly succinct and elegant solutions. However, the lack of generics really forces in some situations to either use the reflection or stop being very DRY or elegant. Go wouldn't have to implement full generics to fix that. Just adding something similar to what interfaces are to methods for variables would do, without the rest of the moving parts.

loosescrews 12y ago
So type classes?
waps 12y ago
First of all, you're making the enterprise java argument. Which is valid, but drives me to suicide. Furthermore ... Go ... succinct ... elegant ... using reflection as an alternative to generics ... In my experience Go is neither succing (if err { ... } one-statement if err { ... } one-statement if err { ... } one-statement). It is extremely inelegant because due to the confused sequence of statements it isn't possible to keep your thoughts on what the method is doing, as there are constant error handling concerns everywhere (or regrets/TODOs about error handling to be completed in the future ...) Is this (if this doesn't refer to itself or the sentence it's in, return that information to the caller manually so he can ignore it) somewhat (if the above statement is not and adjective you have a problem with your understanding of english, report to the relevant authorities) unclear (if un doesn't result in the reversal of the meaning of the word clear, we have a problem and should inform the main sentence interpretation routine that understanding is flawed) perhaps (missing error checking) ? (if the above is not punctuation, report back that your browser is probably not using the correct character set) Using reflection as an alternative to generics is horrible in lots of ways, but just mentioning a few : no type safety (not even a decent verification you're passing the correct number of arguments). It's extremely long code, full of edge cases (such as arrays being a value type and slices being a reference pointer despite differing only in a single character). And it's sloooooooooooooow. As in ruby slow. And you forgot Go crashes. If you think C++ error messages are long, you haven't seen a nil-pointer dereference in Go.
- sacado2 12y ago
  Go's philosophy is to consider errors and failures are part of solving problems, not something "exceptional" that should make you fail and refer to a higher authority. Error-checking and error-reporting is not something that is distracting the normal flow of your function : it is part of the normal flow of your function.
  - waps 12y ago
    First except of course for the corner cases that Go thinks should not be accounted for. These include serious system failures (e.g. gc fails for some reason), memory allocation failures, and of course anything that calls panic. Other errors are effectively impossible to be handled (e.g. system is thrashing and Go's gc runs - you'll never see your program again). So this can't be solved. So please don't say Go doesn't have exception handling. It has code that detects exceptional conditions and attempts to handle them by unrolling the stack. Of course that's entirely different from "exceptions", right ? Plus it once again points out the schizophrenic nature of Go. Go uses error codes. Except when it doesn't. Go doesn't have generics. Except when it does. Go doesn't allow polymorphism. Except in ~5 cases. No language on the planet allows for return type polymorphism (meaning of the function changes depending on what you assign it's result to) ... except of course Go. This was one of the main, and valid, objections people had to languages like modula-2, oberon and the like in the past. And maybe I'm getting old, but my money's on that the pendulum will swing back again. Furthermore I disagree with your assessment. Go and C insist on the same thing : in-line errors. In C that lead to errors being ignored in the vast majority of cases by "average" programmers. In Go ... well, here's the top-5 of Go projects. Go and take a look for yourself : https://github.com/trending?l=go https://github.com/trending?l=go (note: changes every day. Now check if errors are ignored today or not. Today's answer 4 of the top 5 projects ignore almost all errors) But I don't see how your comment addresses the complete unnatural way of thinking that C and Go promote. Handing errors in-line is not natural. This was one of the big complaints when we moved from C to Java/Python, a move supported by a lot of programmers. So let's be honest here. Go's philosophy in practice is to make users ignore errors.
    - 12y ago

loosescrews 12y ago

So type classes?

waps 12y ago

First of all, you're making the enterprise java argument. Which is valid, but drives me to suicide. Furthermore ... Go ... succinct ... elegant ... using reflection as an alternative to generics ... In my experience Go is neither succing (if err { ... } one-statement if err { ... } one-statement if err { ... } one-statement). It is extremely inelegant because due to the confused sequence of statements it isn't possible to keep your thoughts on what the method is doing, as there are constant error handling concerns everywhere (or regrets/TODOs about error handling to be completed in the future ...) Is this (if this doesn't refer to itself or the sentence it's in, return that information to the caller manually so he can ignore it) somewhat (if the above statement is not and adjective you have a problem with your understanding of english, report to the relevant authorities) unclear (if un doesn't result in the reversal of the meaning of the word clear, we have a problem and should inform the main sentence interpretation routine that understanding is flawed) perhaps (missing error checking) ? (if the above is not punctuation, report back that your browser is probably not using the correct character set) Using reflection as an alternative to generics is horrible in lots of ways, but just mentioning a few : no type safety (not even a decent verification you're passing the correct number of arguments). It's extremely long code, full of edge cases (such as arrays being a value type and slices being a reference pointer despite differing only in a single character). And it's sloooooooooooooow. As in ruby slow. And you forgot Go crashes. If you think C++ error messages are long, you haven't seen a nil-pointer dereference in Go.

sacado2 12y ago
Go's philosophy is to consider errors and failures are part of solving problems, not something "exceptional" that should make you fail and refer to a higher authority. Error-checking and error-reporting is not something that is distracting the normal flow of your function : it is part of the normal flow of your function.
- waps 12y ago
  First except of course for the corner cases that Go thinks should not be accounted for. These include serious system failures (e.g. gc fails for some reason), memory allocation failures, and of course anything that calls panic. Other errors are effectively impossible to be handled (e.g. system is thrashing and Go's gc runs - you'll never see your program again). So this can't be solved. So please don't say Go doesn't have exception handling. It has code that detects exceptional conditions and attempts to handle them by unrolling the stack. Of course that's entirely different from "exceptions", right ? Plus it once again points out the schizophrenic nature of Go. Go uses error codes. Except when it doesn't. Go doesn't have generics. Except when it does. Go doesn't allow polymorphism. Except in ~5 cases. No language on the planet allows for return type polymorphism (meaning of the function changes depending on what you assign it's result to) ... except of course Go. This was one of the main, and valid, objections people had to languages like modula-2, oberon and the like in the past. And maybe I'm getting old, but my money's on that the pendulum will swing back again. Furthermore I disagree with your assessment. Go and C insist on the same thing : in-line errors. In C that lead to errors being ignored in the vast majority of cases by "average" programmers. In Go ... well, here's the top-5 of Go projects. Go and take a look for yourself : https://github.com/trending?l=go https://github.com/trending?l=go (note: changes every day. Now check if errors are ignored today or not. Today's answer 4 of the top 5 projects ignore almost all errors) But I don't see how your comment addresses the complete unnatural way of thinking that C and Go promote. Handing errors in-line is not natural. This was one of the big complaints when we moved from C to Java/Python, a move supported by a lot of programmers. So let's be honest here. Go's philosophy in practice is to make users ignore errors.
  - 12y ago