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…
Who's the steward of your language of choice?
The Go Programming Language by Brian W. Kernighan, Alan Donovan
141–150 of 264 posts
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#142Does anyone know if they are selling a digital version?
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#143Earlier quoted context omitted.
I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…
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…
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#144Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.
Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#145Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#146Earlier 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…
Both haskell and probably most lisps are relatively simple languages, compared to python, ruby, c++, etc. I think I have some idea of what you're saying but I'm not familiar with go. > Every single abstraction has a price in complexity. I think the whole point of abstraction is to lessen complexity; wrap up many different things into one thing that's easy to reason about. Very few languages support creating good abst…
Abstraction lessens complexity, and also adds complexity.
Take monads in Haskell, for instance. Let's oversimplify and say that absolutely everything is done through monads. Great; we've now wrapped up many different things into one thing that's easy to reason about. And when I want to do something, I don't have to think at all - I just reach for a monad.
And then I have to think, because now I have to figure out how to make a monad do the specific thing that I actually want it to do.
Or I'm reading the code, and yes, that's a monad, because it always is, because everything's done through monads. But what is this monad at this location in the code actually doing? Well, I have to work my way back out of abstraction to concrete in order to understand that.
One way to think about this is abstract art. As art gets more and more abstract, at first I can't tell whether I'm looking at a blonde or a brunette. Then I can't tell whether I'm looking at a male or a female. Then I can't tell whether I'm looking at a human or a chair. And finally, I get to the point where I'm looking at a painting that could be anything, but it's impossible to say what it is. Abstraction has proceeded to the point that communication (between the artist and the viewer) has been lost. In the same way, abstraction in code can proceed to the point where communication between the author and reader is lost, and then it takes a lot of work to wade through the layers of abstraction to find out what the code is actually doing.
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#147Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.
The "not quite a field" of programming, has a famous history of being full of smarmy naysayers being spectacularly wrong. It's no wonder that the few of us who aren't bratty and quickly judgemental tend to become famous and successful. (Nor that a famous blogger once said that everything he needed to know about managing programmers, he learned from the book, "How to Talk to Your Five Year Old.")
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#148Earlier quoted context omitted.
I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…
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…
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#149Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.
I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitive…
Complexity is also the mind killer. However, it kills with ten thousand cuts, not with one fell stroke. This is why the prideful are even more vulnerable!
Re: The Go Programming Language by Brian W. Kernighan, Alan Donovan
#150Earlier quoted context omitted.
In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors). This…
Yeah, but aside from the singular issue of generics (which are not exactly cutting edge), I can't think of a single 'advanced' feature that would add nearly enough utility to pay for its additional complexity. Everyone who shows up complaining about how it isn't "moving forward" by embracing features of high complexity and dubious utility is really missing the point IMO.
It's fine for languages to embrace those features, and be what they are, and it's fine for Go to reject those features, and be what it is. We don't need "one language to rule them all".