Earlier quoted context omitted.
C# had the exact same pitfall and it was recognised years ago. It's unfortunate that it made it in to Go.
Did they introduce a language solution for it in C#?
[deleted]
Clojure core.async and Go: A Code Comparison
41–50 of 81 posts
Re: Clojure core.async and Go: A Code Comparison
#42Earlier quoted context omitted.
C# had the exact same pitfall and it was recognised years ago. It's unfortunate that it made it in to Go.
Did they introduce a language solution for it in C#?
C# 5.0 is changing the behavior of the loop variable to be logically inside the loop [0].
Re: Clojure core.async and Go: A Code Comparison
#43I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?
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.
Re: Clojure core.async and Go: A Code Comparison
#44FYI, there's a typo: "it’s on yet available" -> "it’s NOT yet available"
Re: Clojure core.async and Go: A Code Comparison
#45This 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…
I've implemented Go-style channels in Python, and it turned out pretty well. The 'select' statement is a bit verbose, but still pretty readable.
You can find the code here: http://github.com/stuglaser/pychan
And documentation here: https://chan.readthedocs.org/en/latest/
Re: Clojure core.async and Go: A Code Comparison
#46Earlier 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.
I think you can be pretty proficient in writing regular Clojure and still find macros "twisty". Most Clojurians would agree that "The first rule of Macro Club is Dont Write Macros".
Re: Clojure core.async and Go: A Code Comparison
#47Earlier quoted context omitted.
You could presumably do this with core.async, but the more idiomatic solution to generators would be lazy sequences.
Oh for sure, more as an exercise in curiosity than anything else. (Although I am also playing with generator- and iterator-like abstractions as part of a resource-scoped foldable stream abstraction to help process big files.) Looks like I managed to answer the 'is it possible?' part of the question anyway -- something like this: (defn range [n] (let [c (chan)] (go (loop [i 0] (>! c i) (if (
Yes, but I wouldn't do that. Every time you pull an item out of the channel, you actually submit a task to execute in a separate thread pool (to produce the next number), block your own thread, and wait for the task to complete on its thread and then wake your thread up. That's a lot of task-switching going on just to generate the next consecutive number :)
OTOH, you could use async's coroutine code (used to implement go blocks) to create generators, but because you have lazy sequences, that's not necessary either.
Re: Clojure core.async and Go: A Code Comparison
#48Earlier quoted context omitted.
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.
I think you can be pretty proficient in writing regular Clojure and still find macros "twisty". Most Clojurians would agree that "The first rule of Macro Club is Dont Write Macros".
Well, I wish that meme would stop too. It makes macros sound all freakazoid, when really they're just another technique.
The obvious and natural and historically standard guidance is "Don't write a macro when a function will do."
Re: Clojure core.async and Go: A Code Comparison
#49Totally off topic, when i see ")))))))" it makes me want to run the other way.
Re: Clojure core.async and Go: A Code Comparison
#50Totally off topic, when i see ")))))))" it makes me want to run the other way.
I'll add the classic response of "once you let your editor just handle it for you you forget about it entirely". Because, really, truly, when you code in lisp you're just traversing a very simple syntax tree. If you use emacs/paredit you literally stop typing and start using keyboard commands to "descend down the left branch" or "prune upward 4 times" or "delete this entire branch".