3 ms·

I think that I have decided to continue reading SICP and work only the exercises that are absolutely necessary for understanding new concepts. I skimmed the re

I think that I have decided to continue reading SICP and work only the exercises that are absolutely necessary for understanding new concepts. I skimmed the remainder and I think that there is some essential information that I should know.

hga 16y ago
Probably a good idea. While the lure of doing stuff now is justifiably strong, spending time building your foundation will pay off heavily and there's nothing better since SICP is working for you. Pretty obviously you should work your way through chapter 3, and you owe it to yourself to discover the coolness in 4.1 at some point. And then if you want to do Clojure, Haskell or other languages with laziness that sets you up for SICP's introduction in 4.2. 4.3-4 get into research areas Sussman did in times past (don't know about Ableson), chapter 5 is one of many useful introductions for how things work all the way down to the metal. Someday, you can be pretty sure you'll be damned glad you learned that level of material, although studying it from a C centric perspective is also useful since it's so ubiquitous. Anyway, have fun and I wish you luck on your projects.
- aeroegnr 16y ago
  Thanks for the inputs, I'm finding SICP too enlightening to put down entirely without finishing it. Is it C itself that is important, or just the concepts? Most of the concepts seem to be contained in what I learned when I took C++ (and have used on some projects). For example, function pointers made one of the projects I was working on very simple. I have a copy of K&R laying around that I haven't worked through, and thumbing through it seems pretty similar to what I saw in C++. I tested myself earlier today while on a layover by SSHing into my server and trying to make some simple C++ code to play with pointers, but since I didn't have the reference I couldn't debug a situation where I was dereferencing a pointer... Maybe I'll look into that a bit if I end up needing a similar feature. I'm torn a bit on exactly what language to hit the ground running with, as far as building actual products. Clojure looks interesting, but I also haven't decided if I want to make something platform-independent and running on the JVM or not, or go all the way with SBCL (and the help of PG's and Peter Seibel's books). I think I'm letting myself get paralysed by too many options (although certain ideas of mine are MUCH easier to do in a Lisp).
  - hga 16y ago
    The concepts, but they're generally taught in C and/or sometimes nowadays x86 assembler (previously the MIPS processor was popular). Going all the way to C++ adds complexity that's not needed for this sort of thing and probably most artifacts (e.g. most GNU projects, Linux, embedded systems and device drivers) are written in C, not C++. Some newer stuff like LLVM and Hotspot (Sun/Oracle's JVM) are written in C++ (and a lot of assembly for Hotspot). I'm talking about the sorts of things taught in this CMU class and its associated book: http://www.cs.cmu.edu/~213/ http://www.cs.cmu.edu/~213/ which includes stuff below the level of C which you should learn, e.g. two's complement arithmetic (fixed point integers), IEEE floating point bit layouts, etc. You don't need to get as hard core as the CMU course/book, but if you know some of these basics, have some idea of how GC works down to the level of pointers etc., you'll be in the long run happier for it. And, yeah, it's easy to get overwhelmed by options. Common Lisp is old, more than a bit crufty (it's mainline LISP going back to the first versions), but there's lots of good stuff out there if you're willing to tinker a bit (and perhaps the latest effort at providing a common library is going to work). It's biggest problem it that it was frozen in amber in the '80s, well before anyone thought to standardize networking or rather critically concurrency plus other stuff (does it have a Unicode story???). Scheme is pure and has been extremely slow to standardize; the most recent attempt to fix that (R6RS) met with massive rejection and who know's what's going to happen next (well, actually I haven't been following it due to the next and last option). It's great for eduction and language research and development (e.g. Javascript is largely Scheme semantics with a C face and a prototype based object system). Clojure is exciting, watching it right now it like watching the middle phase of the Lisp Machine's development except that I think it's just past the stage of serious breaking changes. Things are rough around the edges but a whole lot of people believe it's the future of Lisp. It also is by far the most functional of these three. Common Lisp is so old it had to be multiparadigm (e.g. PROGN and the LOOP macro), Scheme can be programmed functionally but Clojure enforces it a lot more strongly and makes it fast due to a recently developed data structure that largely solves the functional programming trivial update problem. And that allows it to tackle what I find to be the most interesting language problem, multicore single address space concurrency. It's sufficiently functional to allow STM to work (which is generally impractical to bolt onto an imperative language), plus it has several other mechanisms, all of which can take advantage of the immutability of its basic data structures. And the biggest advantage in getting real world things done today is its Java interoperability which is efficient and allows you to use all these Java libraries people have been developing for a decade and a half. Being able to take advantage of what is perhaps the healthiest ecosystem (although, granted, not for the number crunching of science and engineering) is a big win. On the other hand, it does drive up the complexity of what you have to learn and deal with, and has twisted the language a bit here and there. Depending on what you want to do going with either Common Lisp e.g. SBCL or Clojure should do you well. And, yeah, a whole bunch of things are easier to do in a Lisp. There's a reason it's the second oldest surviving computer language, after FORTRAN.

hga 16y ago

Probably a good idea. While the lure of doing stuff now is justifiably strong, spending time building your foundation will pay off heavily and there's nothing better since SICP is working for you. Pretty obviously you should work your way through chapter 3, and you owe it to yourself to discover the coolness in 4.1 at some point. And then if you want to do Clojure, Haskell or other languages with laziness that sets you up for SICP's introduction in 4.2. 4.3-4 get into research areas Sussman did in times past (don't know about Ableson), chapter 5 is one of many useful introductions for how things work all the way down to the metal. Someday, you can be pretty sure you'll be damned glad you learned that level of material, although studying it from a C centric perspective is also useful since it's so ubiquitous. Anyway, have fun and I wish you luck on your projects.

aeroegnr 16y ago
Thanks for the inputs, I'm finding SICP too enlightening to put down entirely without finishing it. Is it C itself that is important, or just the concepts? Most of the concepts seem to be contained in what I learned when I took C++ (and have used on some projects). For example, function pointers made one of the projects I was working on very simple. I have a copy of K&R laying around that I haven't worked through, and thumbing through it seems pretty similar to what I saw in C++. I tested myself earlier today while on a layover by SSHing into my server and trying to make some simple C++ code to play with pointers, but since I didn't have the reference I couldn't debug a situation where I was dereferencing a pointer... Maybe I'll look into that a bit if I end up needing a similar feature. I'm torn a bit on exactly what language to hit the ground running with, as far as building actual products. Clojure looks interesting, but I also haven't decided if I want to make something platform-independent and running on the JVM or not, or go all the way with SBCL (and the help of PG's and Peter Seibel's books). I think I'm letting myself get paralysed by too many options (although certain ideas of mine are MUCH easier to do in a Lisp).
- hga 16y ago
  The concepts, but they're generally taught in C and/or sometimes nowadays x86 assembler (previously the MIPS processor was popular). Going all the way to C++ adds complexity that's not needed for this sort of thing and probably most artifacts (e.g. most GNU projects, Linux, embedded systems and device drivers) are written in C, not C++. Some newer stuff like LLVM and Hotspot (Sun/Oracle's JVM) are written in C++ (and a lot of assembly for Hotspot). I'm talking about the sorts of things taught in this CMU class and its associated book: http://www.cs.cmu.edu/~213/ http://www.cs.cmu.edu/~213/ which includes stuff below the level of C which you should learn, e.g. two's complement arithmetic (fixed point integers), IEEE floating point bit layouts, etc. You don't need to get as hard core as the CMU course/book, but if you know some of these basics, have some idea of how GC works down to the level of pointers etc., you'll be in the long run happier for it. And, yeah, it's easy to get overwhelmed by options. Common Lisp is old, more than a bit crufty (it's mainline LISP going back to the first versions), but there's lots of good stuff out there if you're willing to tinker a bit (and perhaps the latest effort at providing a common library is going to work). It's biggest problem it that it was frozen in amber in the '80s, well before anyone thought to standardize networking or rather critically concurrency plus other stuff (does it have a Unicode story???). Scheme is pure and has been extremely slow to standardize; the most recent attempt to fix that (R6RS) met with massive rejection and who know's what's going to happen next (well, actually I haven't been following it due to the next and last option). It's great for eduction and language research and development (e.g. Javascript is largely Scheme semantics with a C face and a prototype based object system). Clojure is exciting, watching it right now it like watching the middle phase of the Lisp Machine's development except that I think it's just past the stage of serious breaking changes. Things are rough around the edges but a whole lot of people believe it's the future of Lisp. It also is by far the most functional of these three. Common Lisp is so old it had to be multiparadigm (e.g. PROGN and the LOOP macro), Scheme can be programmed functionally but Clojure enforces it a lot more strongly and makes it fast due to a recently developed data structure that largely solves the functional programming trivial update problem. And that allows it to tackle what I find to be the most interesting language problem, multicore single address space concurrency. It's sufficiently functional to allow STM to work (which is generally impractical to bolt onto an imperative language), plus it has several other mechanisms, all of which can take advantage of the immutability of its basic data structures. And the biggest advantage in getting real world things done today is its Java interoperability which is efficient and allows you to use all these Java libraries people have been developing for a decade and a half. Being able to take advantage of what is perhaps the healthiest ecosystem (although, granted, not for the number crunching of science and engineering) is a big win. On the other hand, it does drive up the complexity of what you have to learn and deal with, and has twisted the language a bit here and there. Depending on what you want to do going with either Common Lisp e.g. SBCL or Clojure should do you well. And, yeah, a whole bunch of things are easier to do in a Lisp. There's a reason it's the second oldest surviving computer language, after FORTRAN.