181–190 of 264 posts
Earlier quoted context omitted.
Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.
Is rationality incompatible with subjectivity?
Earlier quoted context omitted.
Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
Have you tried go gen? It looks clearer to me than some of the hoops I've seen set up, jumped through, etc for heavy STL generics: http://clipperhouse.github.io/gen/ It just creates the code for you, then you commit it. Easy enough.
An analogy would be the "deriving" system in Haskell. It doesn't replace the generics system, it just complements it.
Earlier quoted context omitted.
Yeah, fuck this type safety and performance thing...
It's type safe and there's little performance hit. Please note that the "Interface" there is not "interface{}" ... it is a somewhat unfortunately named interface: http://golang.org/pkg/sort/#Interface The Go authors were following a practice that seemed like a good idea at first, and they've now admitted was probably a mistake... i.e. if your package is mostly about a single interface, name the package something info…
Earlier quoted context omitted.
>... it's small enough to keep in your head... While I mostly agree, the flip side of this statement is, the language then does not automatically take care of things that then you have to keep in your head while you're solving the problem. I guess this is the underlying trade-off people make when using "higher-level" or "lower-level" languages. More "powerful" languages do more for you automatically, but you need mor…
The 'magic' that you seem to pine for like is found in lets say Ruby, places a far larger mental burden on the programmer than a language like c or go. Sure, language like Haskell or Rust have a ton of great features and automagical things but I disagree that they are easier to use. One has to keep far more in your head writing Haskell than Go, a clear indicator of this is the difficulty in learning the language. Lik…
Earlier quoted context omitted.
You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens wit…
> Even when the syntax is simple, the conceptual complexity of the language is quite big. Lisp is a very simple language conceptually. The problem is that it allows you to build insane amounts of complexity in a very "free for all" way. No "one sane default way to do it". The problem is now how complex a language is , but how much needless complexity it allows you to build yourself . Go seems great because it doesn't…
Any Turing-compelete language allows you to build arbitrarily much needless complexity. I don't see how it's a useful metric at all, except to say, "Well, this language isn't quite so horribly stunted that you can't even produce a nonterminating program."
If you want to talk about how easy it is to build needless complexity— well, I've yet to see a programming language that knows the difference between necessary complexity and needless complexity well enough to allow the former and prevent the latter. Rather, languages either let you build complex things easily, whether you need that complexity or not, or they just make it a right pain in the ass to accomplish anything.
Personally, I prefer the languages that let me express the complexity of my problem domain easily; sure, I could use them to make things more complex than they need to be, but I don't, because to be quite frank that's just part of being a competent programmer.
Earlier quoted context omitted.
"Ignorance is not a prerequisite for disagreement." This is a very memorable and useful quote. Thanks for saying it. It deserves to be a classic, in my opinion.
Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.
This is only true with identical utility functions for all participants. Rational decision making means each actor acts with perfect information about expected utilities of all options and chooses the option that maximizes their own realized utility. Rational actors can easily disagree without ignorance, since rational actors can have different utility functions.
Earlier quoted context omitted.
Regardless of how I feel about Go as a language... I don't trust Google to perform well as the steward. It may be open source, but that means nothing if people stop working on it. If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only ti…
I don't think you have to trust Google, you just have to trust the core team. While they all work for Google now, the language is open source and they have reputations that extend well beyond their time at Google. I share your distrust of Google, but I trust Ken Thompson, Rob Pike and the rest of the team enough that I don't worry about choosing Go. I have faith that if Google kills it or starts to misbehave, the tea…
Remember when they were building Chrome and how quickly they iterated on it? That was awesome to behold! Maybe a slow pace and a smaller user base is better for developing a language, but if that's the case then I guess I'll just wait another decade before really investing time into Golang.
Earlier quoted context omitted.
>... it's small enough to keep in your head... While I mostly agree, the flip side of this statement is, the language then does not automatically take care of things that then you have to keep in your head while you're solving the problem. I guess this is the underlying trade-off people make when using "higher-level" or "lower-level" languages. More "powerful" languages do more for you automatically, but you need mor…
The 'magic' that you seem to pine for like is found in lets say Ruby, places a far larger mental burden on the programmer than a language like c or go. Sure, language like Haskell or Rust have a ton of great features and automagical things but I disagree that they are easier to use. One has to keep far more in your head writing Haskell than Go, a clear indicator of this is the difficulty in learning the language. Lik…
I don't think that's really true. I think that's a subjective description of a feeling whose presence or absence depends not how any objective difference in the quantity of things that you need to keep in your head with either language, but with how well each language fits one's (subjective) intuition.
Mental load isn't an objective feature of a language, its a subjective feature of a particular programmer's relationship with a language.
Earlier quoted context omitted.
In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is…
http://golang.org/pkg/sort/#Sort So, something like that? Interfaces, man. They're better than you think.