These are indications of the weakness of Java and C, not SICP.
I do not mean this as empty snark; it is something you can see across the board in programming language evolution. It is virtually impossible to propose a new general-purpose programming language today that does not have closure support, which is the biggest thing you're finding missing from C and Java to use the techniques in SICP. (It is not the only thing, but it is the biggest thing.) You'll note Java is going to bolt them on soon, or recently bolted them on, but it'll be another decade before Java is using them fluently either way.
I've often recommend SICP to self-taught programmers; it is not a complete substitute for a computer science education, but it is a concentrated dose of the stuff you're probably missing out on. Expect it to be the work of some months to work through it. However, in the end, a self-taught programmer who has also worked through SICP systematically and carefully is probably a better programmer than 80% of the modern computer science graduates nowadays. (If you want to avoid that fate, oh ye who are still in school, take the freaking compilers course at the very least. Do your peers complain that it is hard? Then maybe it is a good one.)
I don't think a book is "not language agnostic" because two particular languages aren't very good at it. C's lack of closure support is unique among any language still in use, for a variety of reasons. Java... was Java. If you weren't there you may not remember or understand, but at the time OO was at its most dogmatic and either it was an object or it was not included. Anything you could do with a closure could be done with an anonymous inner class. (Which is, technically, true. But the amplification factor on the effort and the sheer quantity of text involved to do so in Java is astonishing.) You can hear some of the echos of this in the older Ruby rhetoric, though I haven't heard it in a while.
Any other general-purpose language you'd be inclined to pick up right now would be fine.
IIRC, you end up implementing a scheme, which you can do nearly in the language of your choice, then the book covers that language you are implementing.
The book is not language agnostic because it's not language agnostic, mostly. The fact that many other languages are a poorer fit for what it's trying to teach is pretty much the definition of 'not language-agnostic'.
I don't know what task could possibly exist for which there are not significantly better and worse languages. Even today's "list of practical projects that anyone can solve in any programming language" [1] I can see at a casual glance that any of them that are not simply trivial will have better and worse languages. A definition of "lanugage agnostic" that either covers no tasks, or covers only very trivial tasks, isn't very useful. (Although in the latter case one can attain some insight by pondering why only such trivial tasks might be considered "lanugage agnostic".)
I'm not sure what any of these logical contortions have to do with SICP being 'language agnostic'. It isn't. The first section of the first chapter talks about why a Lisp dialect is used. This is the first figure.
The "Compiler Design" course at my university was the hardest CS course I've ever taken -- and it was generally taken your very last semester (and was infamous for being a common cause of many senior CS students not graduating on time).
Had it been optional, I would have been sorely tempted to skip it. But, taking it was probably good for me in the long run :)
"I'd find it quite hard to apply lessons from SCIP using java or c"
IMO, you're supposed to write your own Scheme to reap full benefits from SICP.
The book contains a recipe for an interpreter that can be transferred to any other language. Chapter 5.4 : The explicit-control evaluator[0].
Strangely this fact is not advertised that much, I find it to be one of the coollest features of the book.
The implementation is not a direct syntax translation - one needs to figure out how to implement the base susbstrate and how to handle e.g. tokenization, but well rounded software engineer should have some model in ones head how to manage these (so if there are missing pieces this is a good opportunity to brush on those).
After SICP and a little study of functional programming, I started learning about design patterns, and my immediate reaction was, “What’s all the fuss about? I mean ... c’mon ... how else would you solve that problem?”
It took me a while to understand that, if you’ve been raised on Java or C, these things are not obvious at all.
when you start to get to the parts about abstracting a circut, and making it streamy/lazy, you'd find that the impl details of a non-lazy language can make it more difficult than it needs to be.
Also, as a beginner, you don't want both the difficulties of contepts _and_ the difficulties of language to combine to stop you from learning as effectively.
But Scheme isn't a lazy language - granted, you'll need a language that supports first class functions to lift their implementation of a stream though.
>Also, as a beginner, you don't want both the difficulties of contepts _and_ the difficulties of language to combine to stop you from learning as effectively.
Are you referring to the need to learn Scheme to work through SICP? While the asker specifically requested language-agnostic books, Scheme was chosen as a language for SICP for being a "syntax-free" language...
> Are you referring to the need to learn Scheme to work through SICP?
That's not particularly demanding requirement. The class began with a single lecture about how Scheme worked and after that Hal and Gerry assumed you knew all the language you needed to and dove in.
When the course was introduced (early 80s), most incoming MIT freshman had not programmed a computer (!), including those who planned to do course 6 (EE or CS -- 6.001 was a requirement for either degree).
Scheme was chosen as a language for SICP for being a "syntax-free" language...
First-class functions, lambdas, closures, lexical scoping, etc. Abelson wrote, for instance:
"6.001 differs from typical introductory computer science subjects in using Scheme (a block-structured dialect of Lisp) rather than Pascal as its programming vehicle. The subject's developers feel strongly that Pascal is hopelessly constraining, and that important ideas (such as functional programming and object-oriented programming) can be addressed within Pascal only awkwardly, if at all."
