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

Why SICP Matters

cs.berkeley.edu

Post reply on HN
Print view View original

71–80 of 130 posts

Re: Why SICP Matters

#71

Post by davexunit »

webreac wrote: post #35
calinet6 wrote: post #24

Earlier quoted context omitted.

"Scheme has a lot of parenthesis that makes it look very old fashion." Might I argue that this is a huge advantage? No one knows scheme, and it's very obscure, and looks nothing like other programming languages. This means that you can teach concepts using it and pre-judgements about the language don't get in the way. Then, I suppose the same could be said of CAML and its obscurity.

Which one is obscure ? define factorial (lambda (n) (if (= n 0) 1 (* n (factorial (- n 1)))))) let rec fact = function | 0 -> 1 | n -> n * fact (n - 1);; There is a little more syntax to learn in caml, but the suppression of 90% of the parenthesis makes the code far easier to read.

I find the lisp easier to read.

Re: Why SICP Matters

#72

Post by gnosis »

tikhonj wrote: post #65
webreac wrote: post #2

When I was student, my school has decided to stop using Ada as teaching language. They were hesitating between CAML Light and Scheme. They asked me my feeling because I was one of the rare student to know well both of them. I like both of them, but I choose CAML Light. Scheme has a lot of parenthesis that makes it look very old fashion. Scheme type system was also outdated. Programming in CAML Light was more fun for…

The most useful didactic feature I've found in ML-like languages--Haskell for me, but they're all somewhat similar--was pattern matching. Honestly, pattern matching is what really got me to understand recursion. It also makes the language feel much more declarative than using `if` and `cond` statements.

It's possible to do pattern matching in Scheme, though it's not standardized (AFAIK). Here are some approaches:

https://curiousprogrammer.wordpress.com/2006/12/08/pattern-m...

http://www.javaist.com/blog/2008/11/12/pattern-matching-in-s...

http://wiki.call-cc.org/eggref/3/pmatch

http://wiki.call-cc.org/man/3/Pattern%20matching.html

http://www.ccs.neu.edu/home/samth/match-ifl-full.pdf

http://download.plt-scheme.org/doc/203/html/mzlib/mzlib-Z-H-...

Re: Why SICP Matters

#73

Post by tjr »

gnosis wrote: post #70
No1 wrote: post #64

Earlier quoted context omitted.

Does MIT even use Scheme for their intro CS courses anymore? Harvey's article makes it sound like they switched to Python when they went from a "curriculum organized around topics" to a "curriculum organized around applications" - it seems to be the trend everywhere.

MIT did indeed switch from Scheme to Python for their introductory courses (though I've heard they still use Scheme in some more advanced courses).[1][2] However, I recall that a little later some MIT graduate students started teaching their own version of the classic SICP-based course. I can't seem to find a link to it now, unfortunately. I wonder how that turned out, and if they're still teaching it now. [1] - http…

There's a variant of 6.001 that's taught in January IAP sessions:

http://web.mit.edu/alexmv/6.S184/

Re: Why SICP Matters

#74

Post by obviouslygreen »

pimeys wrote: post #57
obviouslygreen wrote: post #51

Earlier quoted context omitted.

Honest interest from someone who doesn't know: While I know this is happening at least some other places in the US (it happened to the one I went to and to at least one a friend attended), is it largely limited to this country, or are other countries seeing similar issues?

My university (Helsinki University of Technology) changed the freshman course from SICP to Java in the beginning of the century. The reason was Nokia, who wanted Java programmers straight from the school. Nowadays they're using Python. I'm very disappointed I didn't have a chance to study that course. I read the book last year and did some exercises by my own. I never had so much fun with any CS book than I had with…

Thanks for the input. I just started learning Clojure and it's blowing my mind... I felt sorry for some friends in college that started with Scheme but now I'm realizing I missed something pretty beneficial.

Re: Why SICP Matters

#75

Post by gmartres »

Fixnum wrote: post #56
gnosis wrote: post #50

Earlier quoted context omitted.

I have experience with OCaml, and I don't find its static typing to be nice to work with at all. I like the final result of safety, and how whole classes of bugs are excluded once I get my OCaml program to compile. But the process of getting my program to compile in the first place is pretty painful and not fun. Then again, writing endless unit tests in a dynamically typed language like Scheme is not much fun either.…

The soon-to-be-released GHC 7.8 (Haskell) can defer type errors until runtime to allow you run your program even if part of it is broken, and you can also add "holes" in place of an arbitrary expression and the compiler will tell you the type of the expression you need to replace it with (of course, this will explode if run). I suspect GHC's error messages are better than Ocaml's as well.

Actually, -fdefer-type-errors is already in GHC 7.6: http://www.haskell.org/ghc/docs/latest/html/users_guide/defe...

-XTypeHoles will be in GHC 7.8: http://www.haskell.org/haskellwiki/GHC/TypeHoles

Re: Why SICP Matters

#76

Post by eru »

gcv wrote: post #61
eru wrote: post #47

Earlier quoted context omitted.

Yes, since at least 80s or so. Languages based on Hindley-Milner type system ( https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner ) are static and nice to work with. E.g. OCaml or Haskell. I have some professional experience in rewriting Python and Ruby programmes in Haskell. I make the same amount of stupid mistakes in Python as in Haskell. But whereas Python blows up at runtime / test time, in Haskell it's the co…

I wrote a simple OCaml compiler for a class in college. I particularly enjoyed using different operators for floating-point and integer math — brilliant usability there, really sold me on static types. Haskell does better with its type classes, except my four attempts to understand monads and arrows have, so far, met with rather mixed success. Static typing has its place in some people's hearts, and I respect that, b…

If you want to have another go at it, I recommend Learn you a Haskell for Great Good (available online for free at http://learnyouahaskell.com/) for your Haskell learning needs. Don't stress the Monads and Arrows so much. I know what arrows do, but can't spot their applications in practice. And still I get paid for writing Haskell programmes.

Oh, and please excuse my snarky tone. Your ancestor comment seemed to ask for it. Yes, they are, even now, languages around that are even worse. But better ways have been around for ages. A similar example is garbage collection: It, too, has been around since basically the dawn of programming languages, but only made serious inroads into the mainstream in the last decades.

Re: Why SICP Matters

#77

Post by eru »

webreac wrote: post #35
calinet6 wrote: post #24

Earlier quoted context omitted.

"Scheme has a lot of parenthesis that makes it look very old fashion." Might I argue that this is a huge advantage? No one knows scheme, and it's very obscure, and looks nothing like other programming languages. This means that you can teach concepts using it and pre-judgements about the language don't get in the way. Then, I suppose the same could be said of CAML and its obscurity.

Which one is obscure ? define factorial (lambda (n) (if (= n 0) 1 (* n (factorial (- n 1)))))) let rec fact = function | 0 -> 1 | n -> n * fact (n - 1);; There is a little more syntax to learn in caml, but the suppression of 90% of the parenthesis makes the code far easier to read.

E.g. Haskell has enough syntactic sugar for some an even simpler version

    factorial n = product [1..n]

Re: Why SICP Matters

#78

Post by hga »

No1 wrote: post #64
SeanDav wrote: post #26

Earlier quoted context omitted.

Sounds like Berkeley are making a huge mistake and losing sight of what a University is there for. They seem to have moved to a more practical approach than theoretical approach. This is the type of approach that is more appropriate to a Technical College than a major University. This new approach almost seems like teaching civil engineers how to weld and rivet in order to build bridges, rather than deeply understand…

Does MIT even use Scheme for their intro CS courses anymore? Harvey's article makes it sound like they switched to Python when they went from a "curriculum organized around topics" to a "curriculum organized around applications" - it seems to be the trend everywhere.

Actually switched entirely to Python and Java. In theory a lot of SICP is taught in the 6.005 Elements of Software Construction course, but since it uses Java, to use Pauli's phrase, for that purpose it's not even wrong.

Re: Why SICP Matters

#79

Post by eru »

spitfire wrote: post #59
eru wrote: post #46

I am revisiting SICP at the moment, because a friend uses it to learn programming. But I have to say, I am not nearly as impressed with the book as I used to be. Wadler's critique "Why calculating is better than scheming" ( http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p... ) fully applies, and the book can be rather confused and ad-hoc in some places, e.g. section 1.3. A stronger focus on data structure…

If you're critiquing the book in such a lucid manner, it sounds like you got good value from it.

I don't deny that. I liked it quite a lot when I read it in my teens, and learned a lot. But revisiting the book in detail has brushed off some of the nostalgia. It is a product of its times.

Re: Why SICP Matters

#80

Post by jimhefferon »

merqumab wrote: post #15
minikomi wrote: post #10

Earlier quoted context omitted.

I think thats the great thing about SICP and its younger, more spritely cousin The Little Schemer - they're both really good to read .

Which would you recommend to read first?

Personally, SICP. I found that the format of LS got old fast.
Post reply on HN