When I shared knowledge and experience in the Go community before, I often heard slang words such as: less is more, less is more, the road to simplicity, the road to simplicity, etc.
Even when discussing Go issues and proposals, some people will use "less is more" to refute or support arguments, which is very interesting. Everyone will be very curious, where does it come from and what does it mean?
Such a deeply rooted community cultural concept must have been proposed by someone with a core. He is the author who said this:
Does anyone recognize it?
He is Rob Pike, the father of the Go language.
Rob Pike has mentioned something like “less is more” on multiple occasions, and it’s a widely circulated idea.
Share on occasions such as:
Various variations of this view are widely circulated in the industry, forming a unique "culture" of the Go community.
Of course, judging from the response from the community, there are both praise and criticism.
Here is a quote from Rob Pike's "Less is exponentially more[3]", the text part@MIKESPOOK[4]Translation, I will reorganize, prune, quote, and illustrate it here, so I won’t reinvent the wheel. I state it clearly.
As shown below:
This is me (Rob Pike) at the Go conference in San Francisco in June 2012 content of the speech.
This is a private speech. I'm not speaking on behalf of anyone on the Go project team, but I'd like to start by thanking the team for everything they've done to make Go possible.
At the same time, I would also like to thank the San Francisco Go community for giving me this speaking opportunity.
A few weeks ago I was asked: “What surprised you after launching Go? What's the most surprising?"
I immediately had an answer: Although we hope that C programmers will learn about Go as an optional language, more Go programmers come from Python, Ruby, and only Very rarely comes from C.
We (Ken, Robert and I) were former C programmers ourselves, and we designed new languages to solve problems in the software we wrote.
And other C programmers don't seem to care much about these problems, which seems contradictory.
Today I want to talk about what led us to create Go, and why it shouldn’t be the way it is. We were surprised by the results.
I promise to discuss Go more than C, even if you don’t know C you can still completely follow the topic.
The answer can be summarized as:Do you think less is more, or less is less?
Here is a true story as a metaphor. As follows:
Of course the management didn't hear the joke, or maybe they didn't want to hear it, but I think there is great wisdom in it. Less is more. The better you understand, the more implicit it is.
Please remember this idea.
Back to 2007 In September, I was doing some trivial but core work on a giant Google C program (the one you all use).
It took me about 45 minutes to compile on that huge distributed cluster.
Received a notification that several people employed by Google working on the C standardization committee will be doing A report.
They will tell us about the improvements that will be made in what was then called C 0x (now known as C 11).
During the hour-long presentation, we heard things like there were 35 features already planned.
In fact there are more, but only 35 features are described in the report. Of course some features are small but significant enough to be worth mentioning in the report.
There are also some that are very subtle and difficult to understand, such as:
At this point I asked myself a question:Does the C committee really believe that the problem with C is that there are not enough features?
Definitely, in another Ron Hardin joke ,Simplifying the language achieves far more than adding functionality. Of course this is a bit ridiculous, but please remember this idea.
Just a few months before this C report, I myself gave a speech, which you can see on YouTube, about a toy-like computer I developed in the 1980s. Concurrency language. This language is called Newsqueak, and it is the predecessor of Go.
I am doing this report because there are some ideas missing in Newsqueak that I thought about again while working for Google. I was convinced that they would make it easier to write server-side code, allowing Google to benefit from it.
In fact Itried to implement these ideas in C, but failed. It's too difficult to tie C control structures to concurrent operations, and ultimately it makes it hard to see the real advantages.
While I admit I've never been really proficient in C, pure C still makes everything possible It looked too bulky. So I dropped the idea.
But that C 0x report made me think about it again. One thing that really bothers me (and I'm sure also bothers Ken and Robert) is that the new C memory model has atomic types.
It feels like an absolute mistake to add such a microscopic collection of descriptive details to an already overburdened type system. This is also short-sighted. It is almost certain that hardware will advance rapidly in the next ten years. It is very foolish to tie the language too closely to today's hardware.
After the report we returned to the office. I started another compilation, turned my chair towards Robert, and started communicating the key issues.
Before the compilation was finished, we had brought Ken in and decided what to do.
We are not going to continue writing C, and we - especially me, want to be able to easily write concurrency when writing Google code.
At the same time, we also want to move forward to control "big programming", which we will talk about later.
We wrote a bunch of things we wanted and their necessary conditions on the whiteboard. Syntactic and semantic details are ignored, and the blueprint and big picture are envisioned.
I still have a fascinating email from that time.
Here is an excerpt:
Robert: The starting point is C, fix some obvious flaws, remove clutter, and add some missing features.
Rob: Named "go". You can make up the origin of the name, but it has a good foundation. It's short and easy to spell. Tools: goc, gol, goa. If you have an interactive debugger/interpreter, just call it "go". The extension is .go.
Robert: The empty interface is interface{}. They implement all interfaces, so this can be used instead of void *.
We didn’t portray everything correctly. For example, mapping arrays and slices took almost a year. But most of the important features of the language were nailed down in the first few days.
Note that Robert said C is the starting point, not C . I'm not sure, but I believe he means C, especially if Ken is around.
But the fact is that in the end we did not start from C. We started from scratch, borrowing only operators, parentheses, braces, and some keywords. (Of course, we also took the best from other languages we know.)
In any case, we are now doing the opposite of C, deconstructing everything, going back to square one and starting again. We are not trying to design a better C, or even better C. Just a better language for the type of software we care about.
Eventually,it became a completely different language from C and C. Each release is getting more and more different.
I made a list of important simplifications of C and C in Go:
Besides this simplified list and some unmentioned trivia, I believe that Go is more expressive than C or C. Less is more.
But even so you can’t throw away everything. There's still a need to structure the way types work, to have proper syntax in practice, and to make the ineffable things of making libraries interact better.
We also added some things that C or C didn't have, such as slice and map, compound declarations, top-level expressions per file (an important thing that was almost forgotten), reflection, garbage collection, etc. . Of course, there's also concurrency.
Of course what is obviously missing is type hierarchy. Please allow me to say a few foul words about this.
In the original version of Go, someone told me that he couldn't imagine working in a language without generics. As mentioned somewhere before, I think this is an absolutely magical review.
To be fair, he was probably using his own way of expressing how much he liked what STL did for him in C. For the sake of debate, let's give him the benefit of the doubt.
He said that writing containers like int lists or map strings is an intolerable burden. I think this is an amazing point.
Even in languages that don't have generics, I spend very little time on these issues.
But more importantly, he said types are the solution to letting go of these burdens. type. Not functional polymorphism, not language foundation, or other assistance, just types.
This is the detail that stuck me.
Programmers coming to Go from C and Java miss the programming style of working with types, especially inheritance and subclassing, and all that goes with it. Maybe I'm a layman when it comes to the genre, but I've never really found this model to be very expressive.
My late friend Alain Fournier once told me that he believed that the lowest form of scholarship was classification. So you know what? Type hierarchy is classification.
You have to make decisions about which piece goes into which box, including the parent of each type, whether A inherits from B, or B inherits from A.
Is a sortable array a sorted array or a sorter expressed by an array? If you believe that all problems are type-driven design, then you have to make decisions.
I believe it is ridiculous to think about programming this way. The core is not the ancestral relationship between things, but what they can do for you.
Of course, this is where interfaces come into Go. But they are already part of the blueprint, which is the true Go philosophy.
If C and Java are about type inheritance and type classification, Go is about composition.
Doug McIlroy, the eventual inventor of Unix pipe, wrote in 1964 (!):
We should connect a piece of pipe in some way like a garden faucet to a hose. Connect message data piece by piece. This is also the method used by IO.
This is also the method used by Go. Go takes this idea and takes it a step further. This is a language about combination and connection.
An obvious example is the way the interface provides us with combined components. As long as it implements method M, it can be placed in the appropriate place without caring what it is.
Another important example is how concurrency connects independently running computations. And there's also an unusual (but very simple) type composition pattern: embedding.
This is Go's unique combination technology, which is completely different from C or Java programs.
There is an unrelated Go design I want to mention: Go was designed for Helps write large programs, written and maintained by large teams.
There is a point of view called "Big Programming". Somehow C and Java dominate this field. I believe this is just a historical mistake, or an industrial accident. But it's a widely accepted belief that object-oriented design can do something.
I don’t believe that at all. Large software does need the protection of methodology, but it does not need such strong dependency management and such clear interface abstraction, or even such gorgeous documentation tools, but it is not more important than powerful dependency management, clear interface abstraction and excellent documentation tools. , and none of these are things that C does well (although Java obviously does better).
We don’t know yet because not enough software is written in Go, but I am confident that Go will stand out in the big programming world. time proves everything.
Now, back to the surprising question I mentioned at the beginning of my speech:
Why does Go, a language designed to destroy C, fail to win the hearts of C programmers?
Jokes aside, I think that's because Go and C have completely different philosophies.
C is to let your fingertips solve all the problems.
I quoted this paragraph from the C 11 FAQ:
C has a much wider range of abstractions, elegance, flexibility, and zero-cost expressiveness than the huge growth of specially written hand-coded code.
This thinking direction is different from Go. Zero cost is not the goal, at least not zero CPU cost.Go's proposition is more about minimizing the programmer's workload.
Go is not all-encompassing. You can't get everything built-in. You can't precisely control every little detail of execution. For example there is no RAII. Garbage collection can be used instead. There is also no memory release function.
What you get is powerful, but easy to understand, and easy to use to build some modules that are used to connect and combine to solve problems.
This may not end up being as fast, as polished, and as ideologically clear as your solutions written in other languages, but it will certainly be easier to write, easier to read, easier to understand, easier to maintain, and safer.
In other words, of course, some oversimplification:
The question then is, does Go’s success refute their worldview? We should realize something from the beginning.
Those who are excited about the new features of C 11 will not care about a language that does not have so many features. Even if it turns out the language has more to offer than they imagined.
thank you all.
I have always been very curious about Go’s philosophy of “less is more”. Where does it come from and what is its meaning?
I read and sorted it out during the Spring Festival. Although the speech contained a lot of content, it was also more colloquial. But essentially what Rob Pike meant by “less is more” is something interesting.
The core point of view is: "The concepts of Go and C are completely different. It is hoped that the programmer's workload will be minimized. Its small number of features should be able to be connected and combined to solve problems, and it should be more expressive rather than heap functions." .
The above is the detailed content of Go design philosophy: less is more, where does that come from?. For more information, please follow other related articles on the PHP Chinese website!