Hacker News new | past | comments | ask | show | jobs | submit login
SICP in Clojure (sicpinclojure.com)
153 points by bernatfp on Jan 17, 2014 | hide | past | favorite | 59 comments




Also when will people understand that SICP is not about teaching programming language? There is no fucking point in rewriting it in your favourite language, it is 99.9% your language less suitable for it (99% it already has mutable state, assignment, loops, (pseudo-)OOP and 5 layers of historic brain damage)

Don't know scheme? But it's even better that way! Many things will faster click in your head. Like oh wtf we're writing programs in some lists. Oh and now how the fuck your interpreter can evaluate programs far more complex than itself?


> it already has mutable state, assignment, loops, (pseudo-)OOP and 5 layers of historic brain damage

You mean like Scheme, right? It's got all that, plus an extra couple of layers now that there's R7RS.


Sure, but this is in Clojure. Surely that's not /that/ far away from Scheme: they're Lisp-1's with pervasive immutability. There's not such an emphasis on explicit recursion, but the loop/recur pattern is still pretty close :) (But yes, you would have to of course translate it from Scheme to Clojure, which means not doing the explicit recursion.)


Scheme and/or Common LISP seem to be the common recommendation to embark on SICP journey, just for reference.


Look at Racket (was Dr Scheme) and use the dialect R5RS

http://stackoverflow.com/questions/939582/which-language-in-...


Use the SICP package for Racket, when you get to the chapters with non-standard functions. For example the chapter on streams and the one about the picture language.

http://planet.racket-lang.org/package-source/neil/sicp.plt/1...


Especially scheme, because it's the language used in the original edition.


An alternative to Racket would be Chicken Scheme. But again, anything that has R5RS included will do fine.

I would not go with R7RS, but this is just a personal preference. Seems bloated to me.


The Heart wants what The Heart wants


The irony is that in Clojure the classic, naive non-tail-recursive factorial procedure from SICP will first result in an Overflow Exception and then in Stack Overflow, while any other Schemes or Lisps could do (fact 1024) easily.

Don't tell me that I should use some bigint type, the whole big idea behind the numeric tower is to do not bother with types.


Maybe that is the reason why Clojure has growing industry adoption while scheme does not. Clojure used to have automatic promotion and all this stuff, but it was taken out in 1.3. BigInts are usful in a very small domain and Project Euler examples, not in many real applications.

If you could start fresh and reprogramm your VM, JIT and GC, it would probebly be good idea to do full numeric tower, but in the real world you have constraints and you cant be pure.


Adoption of Java is a different issue, junk food chains are also enjoys growing adoption, so what?)


You are engaging in the ad populum fallacy fallacy.

That is, you wrongly believe that the popularity of a language isn't, in itself, evidence of its usefulness.

A lot of people making decisions on which language to use are very qualified and knowledgeable. When they choose clojure over scheme, they do it for good reasons.


If I am engaging in anything here, it is not this. You should take a look at my blog at least.)

Clojure is gaining popularity (along with Scala) because it makes living in the Java Ecosystem a bit less painful and disgusting. It has nothing to do with the "decline" (non-popularity) of Common Lisps and Schemes in so-called industry, but more with mediocrity of those for whom this very ecosystem was created and marketed in the first place.


You just assume that it was much better then anything else and people where to stupid and the marketing of the others to good and thats why CL and Scheme see no industry adoption.

This might be true and it might not be true but its sure arrogance to pretend to know that it is true. Your(and other Lispers) arrogance might be a big reason why Scheme and CL never got adopted.


It is pure ignorance on your side to say Scheme or CL never got adopted.


After the AI Winter they where of course still both used, but its absolutly clear that they did not have the addoption other languages had.

At no point was it among the couple of most common used languages at least in the last 30 years. Look at jobs, popularity or any ranking for as we long as we have data.


That sounds different like 'no adoption'. Based on that I would say Clojure has very little adoption. Probably there are a few hundred people using Clojure - not more. The latest State of Clojure survey had just 1000 people taking part. Half of those say they use Clojure at work - where work can be anything from academic to industry.

Clojure has to show a few websites, very few applications and a bunch of hobby projects.

Given that Clojure is at a different point in the hype cycle than Scheme or CL, it does not look like mass scale adoption rivalling Python, Ruby, C++, Objective C or Java is coming soon...

In this light there is absolutely no reason to make snide remarks about CL or Scheme 'industry' adoption, where for example Google uses CL, Sony uses Scheme for game programming, where companies use Siscog's scheduling applications, PTC sells CAD systems, Amdocs uses Allegro Cl in Telco applications, various spae and earth telescopes use a CL-based scheduling engine, various companies use ACL2, NASA has a theorem prover in Lisp, ...

If these apps were written in Clojure we would see large amounts of blog posts, ...


There is an opinion that AI Winter was caused by dramatic spending cuts, which quickly results in "brain power shortage", and has nothing to do with The Common Lisp, which is considered as [modest] success.)


> Maybe that is the reason why Clojure has growing industry adoption while scheme does not

what is "that"? the lack of tail call optimization?


Indirectly, yes. Lack of TCO is a byproduct of being on the JVM, but the JVM is the biggest reason why you can write production systems in Clojure today.


To auto-promote to BigInt in case of an overflow, use a quote after the star(multiplier) operator. Since HN is not allowing me to use star in this comment here is the link to the gist with a simple factorial example: https://gist.github.com/devasiajoseph/8485836


Again, the point is precisely in having just one star.


Only if (recur ...) is not used.

Sure it is a poor man's replacement, but it works.


I'm trying to get my faculty to switch to SICP as the intro to programming course, instead of a planned migration to Python (I'm at the EE department, which is completely separate from CS). Can anyone think of good arguments in favor, which may convince the professors?

So far, my main "ammunition" is Dijkstra's argument that "it provides an environment that discourages operational reasoning":

http://chrisdone.com/posts/dijkstra-haskell-java


You can try to contact the heads of the SOFT group at the Free University of Brussels, they might give you a heap of good arguments and or documents. Thanks to them (and some others), our university still uses SICP as the main course in the first year of the CS education.

http://soft.vub.ac.be/


Thanks for the suggestion. I'll see if I can gather a few supporters before I request their help.


You might want to read this paper by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi who provide interesting points about SICP as well as HTDP as an introductory course in programming: http://www.ccs.neu.edu/racket/pubs/jfp2004-fffk.pdf


SICP is okay for that but if you really want to discourage operational reasoning you should check out courses based on Haskell or ML. I hear the course Bob Harper co-designed is doing really well at CMU.

http://www.cs.cmu.edu/~15150/


Thanks, would love to. But I don't have a fighting chance with that. Pushing SICP through would be an unbelievable feat.


That's a real shame. Bob Harper's philosophy is that the teaching of computer science is more important than the vagaries of one technology industry trend or another. I wish more schools agreed with him.


In their defense, this is EE, not CS. The main thing that matters to them is to get the future engineers proficient in C. When I push for SICP, I claim it will achieve this better than the proposed alternatives, which are all-C and Python-then-C.

Our CS department did use SICP for many years, including when I was a student. Unfortunately they just dumped it, I don't know why. The fact they dumped it makes life even more difficult for me with this...


I don't know what's in the Python course, and they very well could be doing a decent job of teaching CS concepts. However, I'll assume it's a "here's how a for loop works"-type course.

The ultimate utility is ignoring a specific language (Scheme really has nothing to do with the book, and SICP is not a Lisp book per se) and teaching students how to think about computing. It enables problem solving and understanding of the more abstract concepts involved with programming. Scheme just happens to work because there's nothing to the language and there are few boundaries, in terms of functionality.

Honestly, your school can decide if they want to churn out Students Who Program in Python (tm) or students who are taught to teach themselves and can reason about programs on their own, and who feel comfortable understanding varied language concepts. There may be other approaches to accomplish that, but SICP does it well. It's really the only thing that distinguishes a computer science curriculum from a vocational degree, which is an idea that has fallen out of favor or even been lost in the rush to graduate more CS students and embrace "industry standards." Does your school want to educate students or simply teach them programming trivia and practicum that they can pick up on their own? It's an important distinction. Would you want a Linguistics degree that started off by teaching some travel phrases from a Spanish guide purchased at a gas station?

Plus, given the depth of the book, the course could be scaled to a relative difficulty, which would probably be necessary. Recommended pre-reading could consist of the Schemer series (Little & Seasoned) with the expectation that the students might not make it all the way through them before the course starts.

Perhaps you could persuade the faculty to offer a basic Python course and an "honors" CS course that used SICP, or have the SICP course after the Python one, since I think in practice having some basic programming experience is probably a good idea before diving into SICP.

I went Googling for another perspective, and I found http://www.cs.berkeley.edu/~bh/sicp.html, which says a lot of the same things.

People who are new to programming look at SICP and like to say something to the effect of, "Wow, it's a shitty old Lisp book from a bygone error. I actually want to accomplish something, so I'm going to read this O'Reilly Java book now, because I can actually get a job that way." (heavy condescension implied), but perhaps this is a case of the amateur not really knowing what's best for them.

In the end, interested students can always pick up the book in their free time, and you will probably be fighting an uphill battle (at least if you're in the US).

SparkNotes Version: SICP encourages a thought process. A traditional class encourages you to learn how to do X in language Y. It is possible to do the former without SICP, but SICP does it very well.


Wow, the Brian Harvey essay you linked to is exactly what I was hoping to find. A down-to-earth explanation of the benefits, as opposed to Dijkstra's formalism and its potential to alienate non-programmers (in fairness, I only read the first half of it, getting late here). Thanks!

Your explanation is of course along the same lines, and rings true, but I need a "source of authority" (if I can even get someone to listen). Sadly, pre-reading and "honors" are not options at my school, certainly not when a lowly TA pitches them. But this Harvey essay, this might actually work... :-)


Good luck.


Does Clojure differ a lot from Scheme for what SICP teaches? Is there any benefit for studying the Clojure version of SICP, rather than the original?


Yes, the differences are significant. The least reason is tail-call. The point is that Clojure is a very different language, abstracting many of the things that aren't abstracted in Scheme.

The idea of the book (at least in my interpretation) is that you are given a language with the absolute bare-minimum needed to built programs, thus why you can "learn Scheme in an afternoon." All of these things like (filter), hash-maps, dicts, etc, that we use and take for granted in our programs simply do not exist in Scheme unless you build it yourself.

In Scheme, you have to build up all the tools you need by creating your abstractions. To do this in Clojure (or any language) you have to ignore the abstractions you are given, and often must break the abstractions to create the abstractions you are already given.

Think of it this way. If you are going to be learning how to create and explore algorithms for matrix multiplication, would you prefer to use Mathematica or Python without Numpy?


Because the JVM doesn't have tail call optimization, Clojure doesn't allow you to do many of the exercises in SICP the way they were intended to be done, so it misses the point of SICP.

So for example: https://github.com/nickbauman/sicp/blob/master/src/section2_...

You'll see I solved the exercise by ignoring what they were trying to teach because it can't be done in Clojure they way they were trying to teach it. I did learn how to make a tree with only lists, which is cool.


I think it depends on your level of experience. For someone who's a beginner to Clojure and functional programming but wants to use Clojure as their home environment for working through the concepts presented in the book, I suspect they would face some challenges translating the semantics of certain examples in the book, such as streams, to their closest Clojure representation. If you're primarily concerned with just working through the material in the book, you may not want to have to deal with that overhead straight away.


I guess you get to use the Java API, but overall I can't think of any reason to modify the SICP, regardless of everything.

On the bright side, at least it's not JavaScript.


It may be a more useful language, as it integrates with Java libraries. However, there are significant differences between Scheme and Clojure and I'm not sure how well the SICP part survives the translation.


Some the way clojure deals with things is diffrent, everything about state.

Also SICP teach all kinds of concepts from the ground up, its really cool to learn and understand but it has no use other then your learning.


Also matching the RE "SICP in *" we have Martin Henz's JavaScript clone of the first few chapters of SICP: http://www.comp.nus.edu.sg/~cs1101s/sicp/

A (slightly) more readable version is available here: http://ivanistheone.github.io/SICPapp/


Clojure joke:

'knock knock!'

- Who's there?

'minute of silence'

'Knock Knock!'

- Who's there!?

'another minute of silence'

- Java

- Why did you knock twice?

- I didn't, but some other suspicious guy is standing here with raised arm and mouth open.

Based on my recent Clojure on Android experience.


Based on my recent Clojure on Android experience.

As much as I wish Clojure on Android were a viable option, anyone with any sort of reading comprehension knows it's not. So while I don't doubt your criticism may have some sort of merit, you've managed to shoot your credibility in the foot, at least for this particular post.


by what "reading" do you make that claim? I recently saw a really cool game written in libgdx clojure. it looked and played great.


Do not wish, make it.


If had done some basic googling you wouldnot have needed to try it. Everybody know Clojure is not suited to this as it stands.


I'm able to hack fully working UI without restarting my app in minutes while you are still clicking at your first 'button' in XML. Startup time is very slow, but Android nature makes it 'faster' next time, because Android does not terminate applications on exit by default.

So don't lie that 'it is not suited'. There are some fools that actually use it.


its not foolish too. I think some people posting here dont know android or clojure or both.


I remember when "SICP in X" was a thing some years ago. I thought I might as well do a version in a language I use, so I found a text version of the exercises and got to work. I lasted all of 1.5 chapters before passing out from boredom. If translating a bunch of examples of what you can do with lexical scope and singly-linked lists is your thing, go for it, but I'll pass.


but would the metacircular evaluator fit on a chalkboard?

http://ocw.mit.edu/courses/electrical-engineering-and-comput...


I was interested in the same question (how big is a simple Scheme in Clojure?), and ended up working on one for the heck of it. It's a little under 500 lines of Clojure, and it has a very small number of primitives at this point.

I tell myself some day I'll go back and build a read layer so I can have macros.

https://github.com/CJOlsen/fez/blob/master/src/fez/core.clj


if you're in london and working through/thinking about reading/interested in/heard about sicp, let me just shamelessly plug my group here: http://www.meetup.com/London-SICP-Study-Group/

(we use racket)


Where is the coin slot so I can put some money into this awesome project?


holy comment spam batman! well that's a shame...


"You should not be here yet."


I've seen this project before, it's been around and incomplete for a long time. Is someone still working on it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: