Less is exponentially more
commandcenter.blogspot.com
Less is exponentially more
1–10 of 124 posts
Re: Less is exponentially more
#2Here's the video of Rob delivering the talk: https://www.youtube.com/watch?v=JE17r3n1kz4#t=53m5s
IMO it is more compelling when spoken.
Re: Less is exponentially more
#3>Less can be more. The better you understand, the pithier you can be.
The one real weakness of this idea is communicating with others, if you don't share the same understanding you will lose parts of your audience. This is part of the problem with C++ I have read repeatedly on HN (I don't know C++ myself), that everyone uses a subset of the language, but too many use different subsets.
Re: Less is exponentially more
#4The claim that wanting to be able to abstract over types is the same as thinking that programming is about constructing taxonomies is one of the sillier claims I've seen recently.
Re: Less is exponentially more
#5Less is less, but Less might be a better choice if you're particular problem doesn't merit the additional complexity of More.
Re: Less is exponentially more
#6I'm curious how one can file garbage collection under doing less, especially for a language intended for systems programming.
Re: Less is exponentially more
#7Its not just that many programmers want more control. Its also the case that many programmers want more complication. They really prefer the most complicated and difficult way to do things. They don't trust things that are easier or simpler. I think that maybe they believe deep down that ease-of-use versus power is truly a zero-sum game, and you just can't get more of one thing without giving up some of the other. Also, I think that many of them are afraid of losing some of their masculine programmer identity if they adopt an easier way to accomplish things. Also, many of them have invested such an enormous portion of their life and identity to becoming fluent in all of the complications that it is nearly impossible for anything to come around that would make them give up that investment.
But it boils down to the fact that selection of base technologies, like all of the most important human decisions, is generally a NOT rational process, but rather an emotional and subconscious one.
One thing that's interesting to me, and I know this will be hard to buy/comprehend for many Go/C++ programmers, but a similar thing is actually happening with JavaScript versus CoffeeScript.
Its amazing because the languages actually have the same capabilities and the syntactical advantages are so obvious.
Here is an example rationalization against the adoption of CoffeeScript from http://oscargodson.com/posts/why-i-dont-use-coffeescript.htm... :
`` You really need a transpiled language to save you some time from learning the right way to write JavaScript in the first place? Learn JavaScript's pain points and just don't do them.
It's like that C/C++ quote goes:
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." -- Bjarne Stroustrup. ``
Re: Less is exponentially more
#8I'm curious how one can file garbage collection under doing less, especially for a language intended for systems programming.
You might be less curious if you had read and understood the talk. Relevant text:
"That way of thinking just isn't the way Go operates. Zero cost isn't a goal, at least not zero CPU cost. Go's claim is that minimizing programmer effort is a more important consideration."
In a language with closures and Go-style goroutines and channels, the amount of programmer effort required to manage memory would be absolutely immense without a garbage collector.
I believe that "less" as Rob Pike means it doesn't have to do with the complexity of the underlying runtime (though I suspect he'd like that complexity to be as small as possible while getting the job done), but rather the amount of complexity the programmer using the language has to worry about when constructing programs in the language.
Re: Less is exponentially more
#9I'm curious how one can file garbage collection under doing less, especially for a language intended for systems programming.
Covered by Go FAQ: http://golang.org/doc/go_faq.html#garbage_collection
"Another point is that a large part of the difficulty of concurrent and multi-threaded programming is memory management; as objects get passed among threads it becomes cumbersome to guarantee they become freed safely. Automatic garbage collection makes concurrent code far easier to write. Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.
Finally, concurrency aside, garbage collection makes interfaces simpler because they don't need to specify how memory is managed across them."
Re: Less is exponentially more
#10I'll believe it when I see it - anyone have examples of well-written Go compared side-by-side to well-written C++ to show how it is "more expressive"?
Anyway, the benefit to small languages is that it's much easier to design and reason about a consistent and reusable set of language features. The result is overall a superior design, but worse in programmer productivity. Saying "less is more" is just a Turing tarpit.