Live data from Hacker News

Replacing Clever Code with Unremarkable Code in Go

vividcortex.com

91–100 of 140 posts

Re: Replacing Clever Code with Unremarkable Code in Go

#91
post #21

Earlier quoted context omitted.

I'm not sure what your point is, whether you think go is simple and powerful like lisp, or the new java, but simply quoting "The Blub Paradox" makes you sound pretentious (on a site where the largest percentage of readers are probably already familiar with said essay nonetheless). I don't think this is really applicable to the article anyway, since it's an article commenting on two very different languages and progra…

I would agree, and add that simply referencing the article, or quoting relevant portions, along with introducing some original narrative would've been much more productive (conducive to conversation).

And the original pg "Blub" essay is just about the most cultish thing out there...

Re: Replacing Clever Code with Unremarkable Code in Go

#92
post #76

It's so strange to me that people describe things like higher order functions and map/filter/reduce as being clever / complicated and think manual iteration and indexing into an array is "simple". I hate to keep linking to this talk because I don't want to look like too much of a clojure fanboy, but I think a lot of people would benefit from re-examining their definition of simple: http://www.infoq.com/presentations/…

Agreed. This is a wonderful talk for anyone who writes code in any language.

Re: Replacing Clever Code with Unremarkable Code in Go

#93
post #90
post #89

Earlier quoted context omitted.

I haven't seen him comment on generics in languages other than C, C++ and Java. See also below: https://news.ycombinator.com/item?id=5821027

My info came from this thread https://news.ycombinator.com/item?id=5792842 which, now that I think about it, appears to be a bunch of second-hand info about the golang mailing lists. rsc posts here about golang sometimes but I don't think he's mentioned generics specifically.

Perhaps Russ Cox will respond here:

https://news.ycombinator.com/item?id=5796206

Re: Replacing Clever Code with Unremarkable Code in Go

#94
post #68
post #44

Earlier quoted context omitted.

I think this basically nails the attitude of every single go convert that I have spoken to. I am starting to get tired of hearing lines like "that lisp stuff is too complicated, I am a go programmer" or "why would you do x in y way, it's so much better in go". I don't think I have ever seen such unrelenting fanboyism in a programming language. It very well may be a fantastic language but its not an end all be all, we…

Ruby and Javascript were (are?) pretty similar when it comes to fans. It's rather depressing to see how cultish programming is.

Hah, nice pseudonym.

I think it's mostly inevitable, to me it's no different than asking group of farmers which make of pickup or tractor is best, or a deliveryman which brand of shoes are best... I'm pretty sure you could come up with at least one analogue for most any vocation.

In programming, we have: language, practice (formatting, documentation, framework, etc.), methodology (testing, planning), development environment (integrated or otherwise), etc. and each of these is a lightning rod for disagreement. I think it just seems to be more prevalent for software engineers due to the fact that a majority of our discourse occurs online.

Re: Replacing Clever Code with Unremarkable Code in Go

#95
post #86

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at acad…

I recall the launch documentation specifically saying generics are "... a work in progress". Ignoring academic progress is easy when programming is far more often a trade than the application of computer science. I once saw a video comparing Go to an unnamed which matched or surpassed Go in all the ways the video compared the two. The language was Algol 60. Naturally, can't find the video now.

Re: Replacing Clever Code with Unremarkable Code in Go

#96
post #10

> The channel is the analog to the Unix shell’s | character. This sentence was italicized, and rightfully so. I've written a few small Go programs, but I haven't run into a problem where I thought, "A channel is definitely the right solution here." Yet I love and feel quite comfortable with shuffling data through big shell pipelines. Perhaps I'll think of a channel next time I'm reaching for a pipeline.

I find that I use channels mostly when working with goroutines. It's also a convenient mechanism for connection pooling.

Re: Replacing Clever Code with Unremarkable Code in Go

#97

Earlier quoted context omitted.

What does that do? $_ = @_ I can understand.. mod *!8 ..??? Ugh, Perl.

Nothing, it's just gibberish I made up. The worst thing is that it actually looks like plausible Perl :P

Only to someone that doesn't actual know Perl, which tends to be the people who disparage it (see the Blub comment above).

    (()())))lambda())((((())mapcar '5'(34343)()))))
"Lisp" sucks too, just look ^

Re: Replacing Clever Code with Unremarkable Code in Go

#98
post #86

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at acad…

Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model.

> it includes null references, also known as Hoare's Billion Dollar Mistake.

The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true.

> Ain't nobody got time for that — wait, what? Oh, Rust does?

Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust.

> ignoring the last 30 years of programming language research is not.

This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language.

Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives.

And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.

Re: Replacing Clever Code with Unremarkable Code in Go

#99
post #97

Earlier quoted context omitted.

Nothing, it's just gibberish I made up. The worst thing is that it actually looks like plausible Perl :P

Only to someone that doesn't actual know Perl, which tends to be the people who disparage it (see the Blub comment above). (()())))lambda())((((())mapcar '5'(34343)())))) "Lisp" sucks too, just look ^

Well, I know enough Perl to read the non-magical stuff, but I also know that I don't know it well enough to read obfuscated Perl.

Re: Replacing Clever Code with Unremarkable Code in Go

#100
post #86

So, Go has message passing. Just like Erlang, since 1986. Only without per-process heaps, which make crashing processes safe. And without process linking and supervision, which helps systems built using Erlang/OTP achieve nine nines of uptime. Instead, it includes null references, also known as Hoare's Billion Dollar Mistake. But it's not enough to scorn the industry; Go's designers also look down their noses at acad…

I recall the launch documentation specifically saying generics are "... a work in progress". Ignoring academic progress is easy when programming is far more often a trade than the application of computer science. I once saw a video comparing Go to an unnamed which matched or surpassed Go in all the ways the video compared the two. The language was Algol 60. Naturally, can't find the video now.

I haven't seen the video, but here's the article:

http://cowlark.com/2009-11-15-go/

Post reply on HN