3 ms·

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? Mos

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

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.