“I personally don't think SICP will help you much with Clojure. YMMV.”
—Rich Hickey, author, Clojure programming language
SICP in Clojure
31–40 of 44 posts
Re: SICP in Clojure
#32Earlier quoted context omitted.
Check some Python code from Peter Norvig and you will see a beautiful and clever style. It's not the language which stops you.
While I've learned a lot from Norvig's posts, he tends to write Python code that many wouldn't consider "Pythonic" :)
That is just the point, you dont have to limit yourself to "Pythonic". your style can be language agnostic.
Re: SICP in Clojure
#33I've been feeling the past few weeks the repeated impact of hitting a wall. Programming was starting to feel like grinding. I felt wistful for SICP, when programming was full of big ideas and elegant new approaches to problems my unprincipled brain's first instinct was to clobber by brute force -- and learned, quickly, in Scheme, it's hard to be artless. It is, I think, harder code gracelessly in Scheme than to code…
I've been writing Python a lot coming from a Scheme/SICP background too, and I've slowly come to a sort of solution to this problem that works for me. Basically, what it comes down to is realizing that a lot of the libraries and frameworks out there are smoke and mirrors: they provide an initial solution to a common problem, but when you start getting into the details of your problem, the problem you are trying to so…
would love to see an example of your code style...github account?
Re: SICP in Clojure
#34I've been feeling the past few weeks the repeated impact of hitting a wall. Programming was starting to feel like grinding. I felt wistful for SICP, when programming was full of big ideas and elegant new approaches to problems my unprincipled brain's first instinct was to clobber by brute force -- and learned, quickly, in Scheme, it's hard to be artless. It is, I think, harder code gracelessly in Scheme than to code…
I've been writing Python a lot coming from a Scheme/SICP background too, and I've slowly come to a sort of solution to this problem that works for me. Basically, what it comes down to is realizing that a lot of the libraries and frameworks out there are smoke and mirrors: they provide an initial solution to a common problem, but when you start getting into the details of your problem, the problem you are trying to so…
Precisely!
I've been bitten by the data-oriented design bug and it has made my experiences with programming so much better. It turns out Python is really good at this style of programming. There are powerful ideas in co-routines and sub-generators that make stream processing minimal and easier to grasp. Simple ideas like decision tables are so easy to implement that I cringe when I see giant state machines serialized across several classes. Implement backtracking with a stack? Why bother -- functions live on a stack and push/pop: yield-from/yield. We can serialize the state of a co-routine... boom, concurrency. Sometimes it's the little things in Python the surprise me the most and are the reason I keep using it.
Avoid classes where you can! Design your programs around your data. Python has plenty of built-in patterns for manipulating data and aggregates. It's sometimes surprising how simple your programs become when you resist the temptation to start modelling your problem as classes.
I would never discourage someone from pursuing Scheme or Lisps in general (Have you seen Hy? Homoiconic front-end to Python's AST). Scheme does encourage thinking about problems as recursive functions. If iteration is a special case of recursion than Python is breaking ground in the same direction just in different clothes.
Re: SICP in Clojure
#35I've been feeling the past few weeks the repeated impact of hitting a wall. Programming was starting to feel like grinding. I felt wistful for SICP, when programming was full of big ideas and elegant new approaches to problems my unprincipled brain's first instinct was to clobber by brute force -- and learned, quickly, in Scheme, it's hard to be artless. It is, I think, harder code gracelessly in Scheme than to code…
I dunno. I spent some time learning Clojure but came to the conclusion that it's really only a good tool if you are also heavily committed to Java -- too many Java stack traces, too many functions where the answer is "use Java", too much time looking at Java source code. I don't hate Java, but that wasn't what I was hoping for. (Haskell is a different story, very different pros and cons.)
Interesting you have been spending time looking at Java source code, what problems were you trying to solve?
I have been working professionally with clojure for about a year and haven't had to look at any Java source code.
Re: SICP in Clojure
#36Earlier quoted context omitted.
While I've learned a lot from Norvig's posts, he tends to write Python code that many wouldn't consider "Pythonic" :)
That is just the point, you dont have to limit yourself to "Pythonic". your style can be language agnostic.
I agree with you in spirit, but that's actually easier said then done in a professional environment.
One of the things that dissuaded me from ruby was the idioms that have surfaced recently. I was tired of submitting pull requests, only to have people tell me there was a "more idiomatic way" to do things, then rewriting things in a way I felt was less clear then what I had originally written.
My solution to that problem was to find a community who's idiomatic ideals more coincided with mine (which happens to be clojure), but I understand not everyone has that sort of luxury.
Re: SICP in Clojure
#37There's also http://ecmendenhall.github.io/sicpclojure/pages/contents.htm... which is an actual translation of the book into Clojure, currently up to chapter 2.1.4.
And the ill-fated sicpinclojure.com site, which looked beautiful and had such great promise, but mysteriously stalled and died.
Looks like vqc below has done quite a few of the exercises. Nice.
Tommy Hall's SICP Distilled seems like the best shot at a complete book now. It's running a bit behind schedule but appears to be in the home stretch. We'll see!
Re: SICP in Clojure
#38“I personally don't think SICP will help you much with Clojure. YMMV.” —Rich Hickey, author, Clojure programming language
My guess is that this is being taken out of context.
I don't want to put words in Rick's mouth, but I imagine that he means that SICP won't help you learn Clojure the language. Not that SICP won't make you a better programmer in Clojure (and all other languages).
Personally I found it helpful to work through the book in scheme (the language used in the book), porting some of the exercises to Clojure and other languages I'm interested in as a supplement.
Re: SICP in Clojure
#39I've spent a lot of time with SICP and with Clojure. The book changed my life, and I too considered working on "porting" the book, but there would be a considerable amount of friction. Clojure can do everything necesssary, but it's very unidiomatic to build data structures out of pairs in Clojure, and SICP spends a _lot_ of time implementing data structures with pairs. A reconsideration of SICP for the modern age would, I think, take vectors and maps and sets as given, and see what _additional_ magic could be built from there!
Just start with sequences. Lazy sequences, which are so helpful in the expert system database that's built in SICP, are already right there in Clojure without the complications of force and delay. My thought is you could do a lot more with the higher level examples, but a lot of the first half of the book would have to be rethought. (The functional implementation of Conway's Life in O'Reilly's "Clojure Programming" is as good as anything in the first third of SICP, for example; the example of accelerating series convergence from SICP seems less exciting today than it used to, at least to me.)
Re: SICP in Clojure
#40Earlier quoted context omitted.
I dunno. I spent some time learning Clojure but came to the conclusion that it's really only a good tool if you are also heavily committed to Java -- too many Java stack traces, too many functions where the answer is "use Java", too much time looking at Java source code. I don't hate Java, but that wasn't what I was hoping for. (Haskell is a different story, very different pros and cons.)
Interesting you have been spending time looking at Java source code, what problems were you trying to solve? I have been working professionally with clojure for about a year and haven't had to look at any Java source code.
Mostly trying to better understand clojure constructs and their edge cases. I guess I was expecting a more lisp-y setup where high-level concepts were implemented in terms of a small number of clojure primitives, but it didn't seem to work that way. Probably made it perform better, but it also makes it harder to do anything about the endless Java stack traces.