Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less is exponentially more

commandcenter.blogspot.com

Post reply on HN
Print view View original

11–20 of 124 posts

Re: Less is exponentially more

#11

Post by larsberg »

It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers.

It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compiler writer myself (albeit a research compiler, Manticore), ownership dramatically changes your attitude towards using a language. Optimization limitations become "small bugs to fix when you run into them" rather than a "reject this tool as unusable" issue.

Re: Less is exponentially more

#12

Post by georgemcbay »

billswift wrote: post #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.

This is absolutely a problem with C++ and a problem that Go neatly sidesteps via simplicity.

In my career as a C++ programmer (thankfully, I almost never write C++ code anymore), I've met lots of people who used it only as C-with-classes, others who used many more features but avoided templates, others who used templates but only via the STL, others who went whole-hog with template metaprogramming; some who use exceptions for basic flow control, others who avoid that but still use exceptions for exceptional circumstances, some who avoid exceptions altogether, etc.

Having each person use their own subset of the language is fine and dandy if you live in an ivory tower and never need to interface with another developer's code, but of course that is not at all how software development works anymore and eventually you'll be in a situation where you have two chunks of C++ code you need to couple together and they have almost completely alien interfaces to each other (lack of string as a built-in language type also contributes to this greatly, especially since many people avoided the STL for so long).

Go makes a lot of these decisions for you in a way such that doing things in the non-Go way is actively difficult while doing things the Go-way is nearly painless.

If you come into the language wanting to write it like C++ or any other language and you insist that it bend to your will, you probably won't like it. If you come into it with an open mind you start to really appreciate the ways in which it has made decisions for you. Even if you don't agree 100% with the decisions it made, the reasons why those decisions were made can always be reasoned out and the consistency enforced by those decisions is well worth the learning curve it takes to get used to them (IMO).

Re: Less is exponentially more

#13

Post by dsymonds »

larsberg wrote: post #11

It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers. It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compi…

There's lots of companies using Go for serious work these days. It's not just Google.

Also, Go is an open source project. A company that cared could make their own internal folk and modify it as much as they want.

Re: Less is exponentially more

#14

Post by luriel »

larsberg wrote: post #11

It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers. It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compi…

There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go:

http://go-lang.cat-v.org/organizations-using-go

Re: Less is exponentially more

#15

Post by pubby »

ilaksh wrote: post #7

Its 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. Al…

I imagine using Go to write high-performance code or interact well with system libraries is not easier or simpler than a C++ approach, and certainly having worse results.

Also, the comparison to CS/JS seems unfair as Go is not just a syntax change to C++ and has very different a programming style and design goals.

Re: Less is exponentially more

#16

Post by DeepDuh »

georgemcbay wrote: post #8
DeepDuh wrote: post #6

I'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 imme…

I agree that it's always a target conflict. I'm just not convinced that gc is the way to go in an environment where optimization might become important. GC lets you get a correctly working program easier, but once you are into optimizing runtime performance you quickly loose that advantage, often by simulating memory management with pools. Take a look at the new Obj C with automatic reference counting. It lets you forget about the standard case and only requires you to take action for circular reference by defining them weak - thus it replaces a hard problem to solve with an easy one. For my taste that's the right balance in an environment that is run close to the hardware.

Re: Less is exponentially more

#17

Post by luriel »

pubby wrote: post #10

I'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.

> The result is overall a superior design, but worse in programmer productivity.

Go (or its current implementations) might have many deficiencies, but I think almost everyone that has used it for any minimally sized project will agree programming it Go is much more productive than C++.

Some quotes about how productive people are with Go: http://go-lang.cat-v.org/quotes

Re: Less is exponentially more

#18

Post by ilaksh »

pubby wrote: post #15
ilaksh wrote: post #7

Its 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. Al…

I imagine using Go to write high-performance code or interact well with system libraries is not easier or simpler than a C++ approach, and certainly having worse results. Also, the comparison to CS/JS seems unfair as Go is not just a syntax change to C++ and has very different a programming style and design goals.

Maybe it would be better to learn more about Go and rationally evaluate its use in those cases rather than using your imagination.

I'm not sure what you mean by unfair. Its certainly far from an exact analogy but there are interesting similarities.

That is true that Go is not just a syntax change to C++ and that it has a very different programming style. Many of the design goals of Go may be different, but maybe not quite as many as you think. My impression is that a primary design goal for Go is to be a powerful systems programming language allowing high performance processing, especially (but not instead of) via parallelism.

Re: Less is exponentially more

#19

Post by munificent »

I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features):

On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing all artifice, leaving only pure creation.

On the other side, take a look at your average real workshop: a mechanic's garage, a woodshop, or an operating theatre. They are filled with tools. Mastery is knowing a hundred different implements, each carefully designed for one or a few uses. Mastery means having tamed a thousand tools and knowing which one is the perfect one to apply to the situation at hand.

Programming languages live on a continuum between these points. Over in Zen land, you've got Scheme and Go, maybe Smalltalk and JavaScript. Over in everything-but-the-kitchen-sink territory, you've got Java, C#, Common Lisp, and C++.

The first image certainly seems cooler: you as code ninja wielding vi and lambdas with deadly precision. It's the aesthetic of the artist and intellectual. The second image is blue collar, the tradesman, the kid who took shop class for four years, the vocational school graduate.

If we accept the second image, that says something deep and maybe unpleasant about how we look at our work. But, honestly, I think the reality is that quality professional work often looks like the second picture. Every time I go to Home Depot and get some random tool that only does one thing (basin wrench, water heater element remover, you name it), it takes a job that would be hours of frustration and turns it into child's play, and the quality of the work is better.

Simplicity is a virtue worth striving for, but I think it's also valid to want tools perfectly suited for certain tasks. The real art is balancing the two.

Re: Less is exponentially more

#20

Post by kjhughes »

I have a favorable impression of Go after reading this post, however...

The main argument that less is more is essentially the MIT approach of Richard Gabriel's classic Worse is Better concept. It merits mention.

Post reply on HN