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

41–50 of 124 posts

Re: Less is exponentially more

#41

Post by luriel »

chubot wrote: post #28
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 th…

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

Yes, in a way C++ is the worst of both worlds.

I'd like to think Go combines from both traditions and comes to a very nice and useful compromise.

Re: Less is exponentially more

#42

Post by luriel »

rubashov wrote: post #39
greggman wrote: post #30

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…

I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

The interest in a language with even more features than C++ is a mystery to me.

If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.

Re: Less is exponentially more

#43

Post by Symmetry »

Jare wrote: post #26
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).

Type abstractions are fundamentally hierarchical

In C++ or Java they certainly are, but Haskell's type classes, for instance, are much more similar to Go's interfaces.

Re: Less is exponentially more

#44

Post by gfodor »

rubashov wrote: post #39
greggman wrote: post #30

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…

I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

Is it really a mystery? It was created by some of the most well known computer scientists of the last several decades and was created by and for systems engineering at Google.

Re: Less is exponentially more

#45

Post by rubashov »

luriel wrote: post #42
rubashov wrote: post #39

Earlier quoted context omitted.

I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

The interest in a language with even more features than C++ is a mystery to me. If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.

The lack of generic programming in Go is a huge deal. It's vital for modelling complex systems without a mess of runtime checks, and generally leads to clean and reusable designs.

  With D, you can get very close to the generic ideal, "This
  is the last implementation of linear search I'll ever need
  to write." Or binary search. Or stable matching. Or
  Levenshtein distance. I searched around, and it looks
  like D is the only language offering Levenshtein distance
  on UTF strings without copying the input and without
  special-casing per encoding. D just has the abstraction
  power to deal with variable-width entities efficiently
  and within a unified definition (that works with many other
  inputs, such as linked lists of floating point numbers, if
  you want). It's really the last Levenshtein implementation
  I need to write. Now, you may not care about that particular
  algorithm, but there are benefits of that power for many
  structures, algorithms, and design artifacts that might be
  important to you.
http://www.informit.com/articles/article.aspx?p=1621867

Re: Less is exponentially more

#46

Post by pubby »

ilaksh wrote: post #18
pubby wrote: post #15

Earlier quoted context omitted.

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…

I based my assumption off of a quote I heard that was along the lines of, "It is often better to write in the language of the OS when doing systems programming." My personal experience with FFIs and C bindings was extremely boring and tedious. C and C++ may be worse languages but are the obvious choice when dealing with libraries written in their own language.

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

That seems true, although unfortunately the current implementation isn't there yet judging from the Benchmark Game:

http://shootout.alioth.debian.org/u32q/which-programming-lan...

The top implementations for languages like Haskell and CL are both higher level _and_ faster than Go's.

I can't agree more with your quote, "selection of base technologies, [...], is generally a NOT rational process, but rather an emotional and subconscious one." Let's face it, Go is only popular because it's creators are popular. There's nothing really wrong with it, but there's also nothing it truly shines in.

Re: Less is exponentially more

#47

Post by ww520 »

It's pretty cool that GO has "regular syntax (don't need a symbol table to parse)." But isn't that most languages don't need the symbol table to parse? Only languages with ambiguous syntax like C++ needs symbol table.

Re: Less is exponentially more

#48

Post by btilly »

The comment on types reminds me of a very thoughtful comment in _The Structure and Interpretation of Computer Programming_:

"Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call ``ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types. Our own discussion of computational objects in chapter 3 avoids these issues entirely. Readers familiar with object-oriented programming will notice that we have much to say in chapter 3 about local state, but we do not even mention ``classes'' or ``inheritance.'' In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning."

The next time your complex type hierarchy starts to fragment, you might want to think about that.

Re: Less is exponentially more

#49

Post by ww520 »

rogerbinns wrote: post #32

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…

One school of thoughts is that exception is a non-local goto that might span many levels of calls, and that can be non-trivial to understand. Languages without exception has clear paths of return in a function.

Re: Less is exponentially more

#50

Post by ilaksh »

pubby wrote: post #46
ilaksh wrote: post #18

Earlier quoted context omitted.

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…

I based my assumption off of a quote I heard that was along the lines of, "It is often better to write in the language of the OS when doing systems programming." My personal experience with FFIs and C bindings was extremely boring and tedious. C and C++ may be worse languages but are the obvious choice when dealing with libraries written in their own language. > My impression is that a primary design goal for Go is t…

Specifically say you want an application which is both highly concurrent and also binds to some C libraries. How does that actually compare in terms of complexity, ease of adaption for someone with a traditional imperative background, tedium and performance to C/C++ or Haskell/CL?

http://golang.org/doc/articles/c_go_cgo.html

I would also argue that although Haskell and Common Lisp are higher level, they have other issues with complexity, syntax and possibly the actual paradigm, libraries, etc.

Post reply on HN