SICP in Clojure • Hacker News Board

Re: SICP in Clojure

#21

Post by arkx » Tue, Aug 11, 2015, 12:43 PM UTC

adamc wrote: post #19

neoncontrails wrote: post #4

I'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.)

ClojureScript is a very good tool without any Java commitment.

Re: SICP in Clojure

#22

Post by brudgers » Tue, Aug 11, 2015, 12:57 PM UTC

edem wrote: post #13

sbensu wrote: post #12

To the author: on the compound data structures example, it would be much better to return an anonymous function with `fn` than to use `defn`. `defn` is meant to add global definitions to the namespace, not to be used as a value.

This was confusing to me as well since in the Scheme examples they embed functions into each other with define. It may be useful to use letfn to achieve something similar.

Implementing define in a way that allowed it to be used was one of Scheme's innovations relative to some of the other Lisps in the 1970's. It's idiomatic in part because it is easier for new programmers to read and Scheme historically and SICP perpetually are targeted at newer programmers.

Clojure most definitely is not. It's not an accident that Clojure's fn is only two characters. It's design as a language encourages anonymous functions. Along with recur there are many fewer cases where the simpler ways to do something require a name.

The fundamental problem of trying to port SICP to other languages is that SICP is not a book about programming in Scheme. It's a book about software engineering, and the points about software engineering are made in ways that can be readily illustrated in Scheme. Cons is used to illustrate engineering ideas, and while those ideas could be illustrated in Clojure, there's an impedance mismatch between cons and the roughly analogous constructs in Clojure. Part of the baby gets thrown out with the bathwater for little advantage...understanding Scheme probably makes someone a better Clojure programmer, while the force fit of SICP into Clojure probably won't.

Re: SICP in Clojure

#23

Post by taeric » Tue, Aug 11, 2015, 1:21 PM UTC

59nadir wrote: post #14

taeric wrote: post #6

Earlier quoted context omitted.

Swiss clocks feel impressive, no doubt. Quartz clocks, though, have the advantage of being accurate.

This has absolutely no relevance to the analogy.

If you are expecting working code to be as elegant as a "Swiss clock," you might want to reconsider what the goal actually is.

Certainly there is something for coding in this way. Just as it can hold a certain delight to have an elegant looking watch. There is a good chance of overbuilding when I see this level of coding from colleagues. Myself included.

Re: SICP in Clojure

#24

Post by taeric » Tue, Aug 11, 2015, 1:22 PM UTC

dagw wrote: post #16

taeric wrote: post #6

Earlier quoted context omitted.

Swiss clocks feel impressive, no doubt. Quartz clocks, though, have the advantage of being accurate.

A lot of Swiss watches (even from the most high end brands) use quartz movements.

I felt it was safe to assume, for the analogy, that we were talking mechanical watches.

Re: SICP in Clojure

#25

Post by ericmo » Tue, Aug 11, 2015, 1:28 PM UTC

There was another person doing SICP in Clojure too, but it's been frozen in chapter 2 for a couple of years now. https://github.com/ecmendenhall/sicpclojure

Hope this one gets to cover the whole book.

Re: SICP in Clojure

#26

Post by ericmo » Tue, Aug 11, 2015, 1:29 PM UTC

ericmo wrote: post #25

There was another person doing SICP in Clojure too, but it's been frozen in chapter 2 for a couple of years now. https://github.com/ecmendenhall/sicpclojure Hope this one gets to cover the whole book.

Also really interesting: http://xuanji.appspot.com/isicp/

Re: SICP in Clojure

#27

Post by davexunit » Tue, Aug 11, 2015, 2:03 PM UTC

kwhitefoot wrote: post #15

neoncontrails wrote: post #4

I'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…

You can write in functional style in pretty much any language. It might not look quite so pretty but it can come close. And it can often be usably efficient too.

But you always have to make some serious trade-offs. Sure, maybe you can use map and friends, but you usually don't get the nice things like tail-call recursion semantics (though Clojure doesn't have that either), efficient persistent data structures, proper first-class functions (looking at you, Ruby), lexical scope, etc.

I program in a functional style in all of the languages that I get paid to use, but I'm always sad about the lack of many useful features.

Re: SICP in Clojure

#28

Post by vladsanchez » Tue, Aug 11, 2015, 2:04 PM UTC

jahnu wrote: post #11

neoncontrails wrote: post #4

I'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…

A lot of that feeling, at least for some of us, comes from jobs which require us to implement lots of business logic. Business logic often requires coding lots of small conditions distributed all over the code base of an application. Especially once you hit the maintenance phase.

Sounds like a Rules Engine to me. Your description implies a brittle solution that may not be representative of the utopic circumstances pursued by our colleague. Look into Drools. ;-)

Re: SICP in Clojure

#29

Post by rachbowyer » Tue, Aug 11, 2015, 2:22 PM UTC

For those people in London (England) interested in SICP in Clojure, we are running a monthly study group. Our google groups group is https://groups.google.com/forum/#!forum/sicp-mailonline and the code is at https://github.com/MailOnline/sicp-mailonline (each person has their own branch).

We are just starting Chapter 3 and at the current rate of progress it will be at least a year before we have completed the entire book!

Anyone interested is welcome to join us :-)

Re: SICP in Clojure

#30

Post by copsarebastards » Tue, Aug 11, 2015, 2:49 PM UTC

neoncontrails wrote: post #4

I'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 solve, you end up working around their crappy configuration points. In short, you stop coding and start configuring existing code which is poorly designed to solve your problem.

So what I do is I stop using those libraries. I zealously guard my dependencies, only letting in things that are solid, well-designed, mature, and minimally invasive. I use minimalist frameworks, eschewing ORMs. Most of the time I avoid classes, opting instead to use closures and namedtuples. The result, my code is fast, flexible, easy to understand, easy to test. I migrated around 30,000 lines of code from Python 2.7 to 3.4 in an afternoon--my unit tests caught a few issues and once those were fixed I didn't see any regressions in the following months.

I think the wall you're hitting isn't Python, it's the culture and libraries a lot of people use for Python. But there are a lot of people who don't use those things. Next time you think of reaching for pip or Django, stop yourself: do you need that? Maybe it provides a short-term solution to your problem, but in the long run it's neither a beautiful nor efficient way to write code.