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

21–30 of 124 posts

Re: Less is exponentially more

#21

Post by wvenable »

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…

> In a language with closures and Go-style goroutines and channels...

Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

Re: Less is exponentially more

#22

Post by overcyn »

munificent wrote: post #19

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…

Using a hundred different pliars and wrenches doesn't make your car any harder to fix down the road. Using a hundred different types of screw heads does.

Re: Less is exponentially more

#23

Post by enneff »

munificent wrote: post #19

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…

I think you make a good point, but I would argue that Go finds that balance. Sure, Go's design is more ideologically motivated than, say, C++, but it is not ideological to a fault. (And I think Rob hints at this in the article.)

Re: Less is exponentially more

#24

Post by georgemcbay »

wvenable wrote: post #21
georgemcbay wrote: post #8

Earlier quoted context omitted.

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…

> In a language with closures and Go-style goroutines and channels... Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

"Is that also filed under doing less?"

Compared to writing concurrent code in C++... yes, absolutely. No question.

Re: Less is exponentially more

#25

Post by ken »

For some reason I find this sentence rather amusing:

"Starting point: C, fix some obvious flaws, remove crud, add a few missing features."

From what I've seen, they've done some good things with this language, and looking backwards from today, it's clear that C is one of its ancestors.

Yet if I was given a blank sheet of paper with the same sentence, I would end up with a completely different language. In other words, this reads to me like shorthand for "Rob, that thing that's in your head, build that" (which is a perfectly legit thing to say -- I've said it myself).

It's like giving a bunch of people the requirement to fix the "obvious flaws" of automobiles, and someone draws a convertible, and someone draws an electric car, and someone draws a motorcycle, and still someone else draws a bus. Looking backward, you can see where it came from, but looking forward, nobody can predict where fixing someone else's obvious flaws might lead.

I kind of want to hold a contest where I take some ordinary thing that everybody uses but nobody loves, and have a bunch of people all design a new one that just fixes the "obvious flaws"!

Re: Less is exponentially more

#26

Post by Jare »

samth wrote: post #4

The 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.

His claim as I understood it is that the fundamental building blocks should not be types (what something is), but functional capabilities (what something can do). Type abstractions are fundamentally hierarchical (from an abstraction to multiple concrete versions), whereas capabilities are fundamentally about composition (I can do A, B and C).

Re: Less is exponentially more

#27

Post by _delirium »

wvenable wrote: post #21
georgemcbay wrote: post #8

Earlier quoted context omitted.

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…

> In a language with closures and Go-style goroutines and channels... Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

There are several of those languages too, but they suffer from the opposite problem: not enough differentiation to overcome the inertia, tool support, and installed base of C.

The most developed attempt that comes to mind is Cyclone http://en.wikipedia.org/wiki/Cyclone_(programming_language).

Re: Less is exponentially more

#28

Post by chubot »

kjhughes wrote: post #20

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.

It's not the same argument. Worse is better is about whether it's more important to have a simple implementation (Unix/C/NJ style), or a simple interface (MIT style).

This post is arguing about whether it's important to have a lot of features in a language, or whether fewer features is more powerful.

C++ has a complicated interface and a complicated implementation. So it's neither NJ or MIT style.

My perception is that Go has a simple interface but relatively complicated implementation (relative to C). It's actually closer to MIT style, despite having the Bell Labs/NJ heritage. Examples: garbage collection, segmented stacks, and goroutine scheduling. Not saying that's good or bad, but the "guts" aren't exposed as much as in C. Unix and C let all the implementation details poke out. They have simple implementations but complicated interfaces.

I guess garbage collection should be the canonical example of an MIT style feature. The interface is much simpler, but the implementation is extremely complex. And it does poke through that abstraction boundary and bite you.

Re: Less is exponentially more

#29

Post by dchest »

DeepDuh wrote: post #16
georgemcbay wrote: post #8

Earlier quoted context omitted.

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 fo…

1986 - Brad Cox and Tom Love create Objective-C, announcing "this language has all the memory safety of C combined with all the blazing speed of Smalltalk."

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

Once you're optimizing the runtime performance of Objective-C code, you're suddenly writing in C.

The "close to hardware" thing is an illusion created by the "-C" part.

Re: Less is exponentially more

#30

Post by greggman »

Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles.

Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places that use lots of C++?

So at least for me, while I'd love to get the benefits of what Go is trying to achieve, until it solves the problems I personally need to solve it's unfortunately off my list.

When I am on a project it fits I'm looking forward to checking it out.

Post reply on HN