Hacker News Reader

Comment by ceronman | Hacker News Reader

You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens with Haskell and at some point with Rust. In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed.

Note: Rust actually has a chance because it's simple compared to its competition: modern C++.

View on HN

In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed.

Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors).

This is not a critique of Go, just to point out that it is a trade-off, and there isn't necessarily one right answer.

This exactly what I mean when I say that people underestimate simplicity and overestimate features. Yes, generics are a nice feature. Yes they help you to avoid code duplication. Yet, not having them is not a stopper at all. Programs are shipped without generics. Code bases remain clean enough without them. On the other hand, every time I read a generic function in C# or Java I feel I have to double think everything. That's the price of of adding an abstraction layer.

Don't get me wrong, I like generics. I think they would be a nice addition to Go. But I understand Go designers when they try to be conservative about it. I like that they only add features when it's absolutely obvious that the pros overcome the cons.

But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly if I'd known Go better).

But that is so rarely an issue...

For you...

It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats.

Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner.

So, yes, the lack of generics is a frequent issue for me.

Yes, and that does not conflict with what I was saying. There are specific problem domains where generics would simplify matters, but in the overall universe of problems those domains are rare, i.e., most of the code that most programmers will write in Go will not involve duplicating code because of the absence of generics.

I think you slipped in a subtle but annoying mistruth here: "in the overall universe of problems those domains are rare" is just not true. What is true is that the kinds of programs Go programmers typically write may end up not needing this sort of polymorphism, which is very different from saying "domains where this sort of polymorphism is important are rare".

I only point this out because I've seen a lot of Go programmers defend Go by saying parametric polymorphism is only really important in particular niche domains, when really they want to say that Go only focuses on a particular niche domain where it isn't important.

I can't remember the last non-trivial c++ program I wrote that I didn't use generic containers like std::vector or std::unordered_set, or the last java program where I didn't use List.

Yeah, but aside from the singular issue of generics (which are not exactly cutting edge), I can't think of a single 'advanced' feature that would add nearly enough utility to pay for its additional complexity. Everyone who shows up complaining about how it isn't "moving forward" by embracing features of high complexity and dubious utility is really missing the point IMO.

What about sum types (discriminated unions)? Sounds like that would help make error handling a lot safer and easier.

How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)?

The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.

The problem with omitting language features like this is that the programmer is then forced to implement them by hand in an error-prone way. It's the same issue with Python and tail call optimization. Guido refuses to implement tail call optimization, so the programmer has to implement it herself in terms of a loop. Go refuses to implement sum types, so programmers code them up by hand. In neither case is the code actually clearer.

Since proper error-checking in Go actually requires doing by hand what a pattern match would have done anyway you're not simplifying anything for anyone by omitting them; you're just making it harder for the compiler to provide compile-time checks.

A pattern match is basically a switch statement. Go already provides the latter so the language would not need to become more complicated.

Well, they're really missing the point of Go.

It's fine for languages to embrace those features, and be what they are, and it's fine for Go to reject those features, and be what it is. We don't need "one language to rule them all".

http://www.infoq.com/presentations/Null-References-The-Billi...

My low content response is that you are brutally correct.

> Even when the syntax is simple, the conceptual complexity of the language is quite big.

Lisp is a very simple language conceptually. The problem is that it allows you to build insane amounts of complexity in a very "free for all" way. No "one sane default way to do it".

The problem is now how complex a language is, but how much needless complexity it allows you to build yourself.

Go seems great because it doesn't easily allow you to build needless complexity. Though I've never coded anything meaningful in it, so my praise for it would be armchair thinking...

Are you talking about Common Lisp, or are you talking about Scheme? Common Lisp does provide primitives for just about everything, in ridiculously generic forms. Scheme forces you to code it yourself.

I think the criticism leveled would go to both. If what you say is true, moreso to Scheme. But the criticism is more that it allows this. To many, it even encourages it.

For myself, I still like it, a lot. To the point that the more I learn of it, the more I'm confused on how it hasn't taken off better.

> Common Lisp does provide primitives for just about everything

Most of it are not primitives though, Common Lisp only defines 25 special forms. Guess how many keywords Go has?

I would see more 'primitives' in a language than 'special forms'.

For example Common Lisp provides support for complex numbers and operations for them. These operations are 'primitives' in the language. This is unrelated to 'special forms'.

>The problem is now how complex a language is, but how much needless complexity it allows you to build yourself.

Any Turing-compelete language allows you to build arbitrarily much needless complexity. I don't see how it's a useful metric at all, except to say, "Well, this language isn't quite so horribly stunted that you can't even produce a nonterminating program."

If you want to talk about how easy it is to build needless complexity— well, I've yet to see a programming language that knows the difference between necessary complexity and needless complexity well enough to allow the former and prevent the latter. Rather, languages either let you build complex things easily, whether you need that complexity or not, or they just make it a right pain in the ass to accomplish anything.

Personally, I prefer the languages that let me express the complexity of my problem domain easily; sure, I could use them to make things more complex than they need to be, but I don't, because to be quite frank that's just part of being a competent programmer.

Both haskell and probably most lisps are relatively simple languages, compared to python, ruby, c++, etc. I think I have some idea of what you're saying but I'm not familiar with go.

> Every single abstraction has a price in complexity.

I think the whole point of abstraction is to lessen complexity; wrap up many different things into one thing that's easy to reason about. Very few languages support creating good abstractions, unfortunately.

> I think the whole point of abstraction is to lessen complexity; wrap up many different things into one thing that's easy to reason about. Very few languages support creating good abstractions, unfortunately.

Abstraction lessens complexity, and also adds complexity.

Take monads in Haskell, for instance. Let's oversimplify and say that absolutely everything is done through monads. Great; we've now wrapped up many different things into one thing that's easy to reason about. And when I want to do something, I don't have to think at all - I just reach for a monad.

And then I have to think, because now I have to figure out how to make a monad do the specific thing that I actually want it to do.

Or I'm reading the code, and yes, that's a monad, because it always is, because everything's done through monads. But what is this monad at this location in the code actually doing? Well, I have to work my way back out of abstraction to concrete in order to understand that.

One way to think about this is abstract art. As art gets more and more abstract, at first I can't tell whether I'm looking at a blonde or a brunette. Then I can't tell whether I'm looking at a male or a female. Then I can't tell whether I'm looking at a human or a chair. And finally, I get to the point where I'm looking at a painting that could be anything, but it's impossible to say what it is. Abstraction has proceeded to the point that communication (between the artist and the viewer) has been lost. In the same way, abstraction in code can proceed to the point where communication between the author and reader is lost, and then it takes a lot of work to wade through the layers of abstraction to find out what the code is actually doing.

I think HN might find discussions more productive if commenters were more specific when they discussed the simplicity of their favorite tools. Qualifying an entire language as "simple" isn't very descriptive when the word often describes totally opposite languages.

When someone talks about a language, I'd rather they talk about what exactly it is the language simplified and where it hid the rest of the complexity. One can only simplify a Turing Complete language so much before the it starts running up against the limits of Kolmogorov Complexity. After that point, the best we can do is shuffle it around - under the bed, or under the sofa, or inside the closet, or into a corner - depending on each programmer's preferences.

When people talk about abstraction for example, they really mean reducing mental complexity. The pro is that we can reason about a larger percentage of our programs by being able to fit more code into our limited working memory. The con is that something other than our brain (e.g. algorithm w) has to do the heavy lifting. With abstraction, all the little details (the complexity) still exist somewhere, we just don't have to look at most of them.

That would be true if abstraction were a cosmic force that radiated in all directions equally, a Hegelian horror trip anihilating all meaning so to speak.

But most of the time, we are abstracting away something specific in order to make something else more concrete and less obscured by irrelevant detail, hence reducing complexity.

Of course abstraction can go wrong, because sometimes we abstract away things that are very relevant, perhaps in futile pursuit of future code reuse. But having the tools for abstraction does not make abstraction go wrong. We do.

Not that I can completely disagree with your point, but there are many reasons outside of the intrinsics of a programming language that can and will influence ones success.

The marketting muscle that was put behind Java certainly helped it in its time. Same for the actual market that backs objective c.

C probably benefited as much from the open distribution as it did anything else. Combined with a relatively high quality compiler that was heavily distributed (gcc), this can not be understated. The only languages that were as highly distributed were probably the various BASICs, and there are obvious reasons to fall off of those at some point.

So, you can blame lisp's lack of popularity on its complexity. I am not so sure that is a good foundation, though. I feel it is as much lack of a high quality distribution of it as it is anything else.

Though, highly on topic, it should probably be noted that the approachability of the original C Programming Language book that is making so many people excited about this book probably had a very heavy influence, as well. I am not so sure a book can have as heavy of an influence in today's environment, but I think it would be foolish to discount the amount of influence a publication like this could have had back in the day.

I don't think GCC can take any credit for C becoming a popular language. GCC 1.0 was only released in 1987, and prior to that most people were stuck using proprietary compilers. I would rather say C succeeded because it was tied to Unix, and Unix was very successful.

GCC certainly contributed to C continuing to be widely used.

My feeling is that it is fair to say that gcc contributed to linux existing, and linux has had a large positive influence on c's current life.

That said, you are definitely correct in C's early popularity. And that probably contributes more heavily than later items. (There is a term for this, but I can't remember it right off.)

Quite right.

Before UNIX became part of the enterprise workforce very few cared about C.

There is no "Lisp invented in the 50s" that never got widely used. This language doesn't exist. To use that level of abstraction, replace every language in your post with the word "Algol" except Haskell which you call "ML". Doesn't make sense? Neither does your reference to Lisp.

Reply on news.ycombinator.com