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

Clojure core.async and Go: A Code Comparison

blog.drewolson.org

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Clojure core.async and Go: A Code Comparison

#61

Post by mheiler »

gruseom wrote: post #43
JulianMorrison wrote: post #31

Earlier quoted context omitted.

It's the difference between "programmable programming languages" (which the lisps are, as are haskell and ruby) versus "languages for programming in" (exemplified by go and java). Go code is very terse compared to the general run of "languages for programming in". And if you know the language, you can just read it . On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Me…

On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty I wish this meme would stop. Your "if you know the language, you can just read it" applies just as much here as it does there.

The concrete example is a perfect use case for a macro: In other languages you have to understand and change the compiler implementation to achieve the same effect. That's most likely more work.

Re: Clojure core.async and Go: A Code Comparison

#62

Post by sambeau »

JulianMorrison wrote: post #34
mjw wrote: post #30

Quick question for anyone here familiar with core.async: Would it be possible (and if so what would be the simplest way) to implement something like Python's generators and `yield` statement in Clojure using core.async? I'm thinking something like: (defn range [n] (generator (loop [i 0] (yield i) (when ( 0 (generator) ;; => 1 ;; etc )

I dunno, but I can do it in go :-P func generator(values ...interface{}) func() interface{} { c := make(chan interface{}, len(values)) for _, v := range values { c

"The problem with using a goroutine as a generator is that if you abandon it, it will not get garbage collected."

It's also slow.

https://groups.google.com/forum/#!topic/golang-nuts/v6m86sTR...

Re: Clojure core.async and Go: A Code Comparison

#63

Post by JulianMorrison »

sambeau wrote: post #62
JulianMorrison wrote: post #34

Earlier quoted context omitted.

I dunno, but I can do it in go :-P func generator(values ...interface{}) func() interface{} { c := make(chan interface{}, len(values)) for _, v := range values { c

"The problem with using a goroutine as a generator is that if you abandon it, it will not get garbage collected." It's also slow. https://groups.google.com/forum/#!topic/golang-nuts/v6m86sTR...

My design relies on pre-loading the channel's buffer and doesn't use a goroutine.

Re: Clojure core.async and Go: A Code Comparison

#64

Post by adamtulinius »

voidlogic wrote: post #57
chongli wrote: post #55

Earlier quoted context omitted.

That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?

Try this: 1. Step One Goes Here 2. Step Two Goes Here 3. Step Three Goes Here vs Step One Goes Here|Step Two Goes Here|Step Three Goes Here

What you show is what golfing does to readable code, and has nothing to do with the comment of the GP.

Re: Clojure core.async and Go: A Code Comparison

#65

Post by chongli »

mseepgood wrote: post #59
chongli wrote: post #55

Earlier quoted context omitted.

That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?

So APL is the most maintainable and least error prone language?

No. Verbosity != file size. Verbosity is a qualitative measure relative to a minimum, complete expression of an idea.

Re: Clojure core.async and Go: A Code Comparison

#66

Post by chongli »

grey-area wrote: post #56
chongli wrote: post #55

Earlier quoted context omitted.

That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?

Verbosity is never valued in prose Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. Your absolute statement is false when looking at most of the valued literature over the last few hundred years. The more verbose code is, the more prone to error and less maintainable it is. I think this is true, but only to a certain point . Pas…

>Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you.

I don't value verbosity and I do appreciate the works of those authors: I do not consider them verbose. Verbosity is not a measure of the absolute length of a document; it's relative to a minimum expression of an idea. Per this definition, all verbosity is unnecessary because it conveys no additional information.

Re: Clojure core.async and Go: A Code Comparison

#67

Post by nickik »

voidlogic wrote: post #54
nickik wrote: post #29

This is very cool and intressting. I have to think about something to do with core.async. This is also a good example why macros are just awesome. Go is a language design to work well with goroutins and channels, but the clojure code looks just as good and readable. You could simply not have such idiomatic use of these concepts without macros. Or am I wrong, can a flexible language like scala or python be extended to…

>but the clojure code looks just as good and readable. But don't mistake this for having the same runtime characteristics- For what its worth the Computer Language Benchmarks Game shows Go as generally being faster, using much less memory and less code. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

That is true. I have not looked at the much of the clojure code and non of the go code but both probebly are written in a very unidiomitic style that one does normally not use.

Also with clojure, the actual timeconsuming calculations can be made with java and that should be at least as fast as go (with a bit more memory).

So all in all I value the architectural things much more then pure speed. Go simply has a diffrent target then Clojure.

Re: Clojure core.async and Go: A Code Comparison

#68

Post by grey-area »

chongli wrote: post #66
grey-area wrote: post #56

Earlier quoted context omitted.

Verbosity is never valued in prose Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. Your absolute statement is false when looking at most of the valued literature over the last few hundred years. The more verbose code is, the more prone to error and less maintainable it is. I think this is true, but only to a certain point . Pas…

>Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. I don't value verbosity and I do appreciate the works of those authors: I do not consider them verbose. Verbosity is not a measure of the absolute length of a document; it's relative to a minimum expression of an idea. Per this definition, all verbosity is unnecessary because it…

I do not consider them verbose

What a curious statement. James did not consider the 'minimum expression of an idea' a virtue, he's almost infamous for his verbosity, as are many of the others in that list. I'll leave you with something from the start of The Ambassadors as an example:

The principle I have just mentioned as operating had been, with the most newly disembarked of the two men, wholly instinctive--the fruit of a sharp sense that, delightful as it would be to find himself looking, after so much separation, into his comrade's face, his business would be a trifle bungled should he simply arrange for this countenance to present itself to the nearing steamer as the first "note," of Europe.

http://classiclit.about.com/library/bl-etexts/hjames/bl-hjam...

Re: Clojure core.async and Go: A Code Comparison

#69

Post by chongli »

grey-area wrote: post #68
chongli wrote: post #66

Earlier quoted context omitted.

>Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. I don't value verbosity and I do appreciate the works of those authors: I do not consider them verbose. Verbosity is not a measure of the absolute length of a document; it's relative to a minimum expression of an idea. Per this definition, all verbosity is unnecessary because it…

I do not consider them verbose What a curious statement. James did not consider the 'minimum expression of an idea' a virtue, he's almost infamous for his verbosity, as are many of the others in that list. I'll leave you with something from the start of The Ambassadors as an example: The principle I have just mentioned as operating had been, with the most newly disembarked of the two men, wholly instinctive--the frui…

I don't consider that verbose at all. It expresses a great deal more information than you're giving it credit. It would not be easy to pare down without destroying this information. Thus, it is very close to the minimum expression of the intended idea.

Re: Clojure core.async and Go: A Code Comparison

#70

Post by chongli »

voidlogic wrote: post #57
chongli wrote: post #55

Earlier quoted context omitted.

That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?

Try this: 1. Step One Goes Here 2. Step Two Goes Here 3. Step Three Goes Here vs Step One Goes Here|Step Two Goes Here|Step Three Goes Here

No, a proper example would be this:

  1. Step One Goes Here
  2. Step Two Goes Here
  3. Step Three Goes Here
vs

  Steps (One, Two, Three)
Post reply on HN