by pieterr on 11/16/24, 5:23 PM with 180 comments
by __turbobrew__ on 11/16/24, 8:40 PM
I don’t know if distributed systems is consider part of “Computer Science” but it is a much more common problem that I see needs to be solved.
I try to write systems in the simplest way possible and then use observability tools to figure out where the design is deficient and then maybe I will pull out a data structure or some other “computer sciency” thing to solve that problem. It turns out that big O notation and runtime complexity doesn’t matter the majority of the time and you can solve most problems with arrays and fast CPUs. And even when you have runtime problems you should profile the program to find the hot spots.
What computer science doesn’t teach you is how memory caching works in CPUs. Your fancy graph algorithm may have good runtime complexity but it completely hoses the CPU cache and you may have been able to go faster with an array with good cache usage.
The much more common problems I have is how to deal with fault tolerance, correctness in distributed locks and queues, and system scalability.
Maybe I am just biased because I have a computer/electrical engineering background.
by neilv on 11/16/24, 7:18 PM
https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
https://web.mit.edu/6.001/6.037/sicp.pdf
I hadn't seen a blessed PDF version until today. Circa 2001, only the HTML version was freely available, and someone converted it to TeXinfo: https://www.neilvandyke.org/sicp-texi/
If anyone wants to work through SICP today, you can run the code in MIT Scheme, or in DrRacket: https://www.neilvandyke.org/racket/sicp/
by freethejazz on 11/17/24, 2:26 AM
I still find their description of how to create and group abstractions in various layers to be useful personally and as a mentor. (In the videos, lesson 3A, 1:07:55)
by MikeTaylor on 11/16/24, 9:20 PM
by globular-toast on 11/16/24, 10:58 PM
by jll29 on 11/17/24, 10:17 AM
After many years of hobbyist programming (and consuming 'structured programming' books as well as languages from Pascal to Common LISP) we used Abelson & Sussmann at my undergraduate comp. sci. course, and it was eye-opening.
It demonstrates the simplicity, beauty and interactivity of Scheme while teaching you that computer science is the layering of different kinds of abstractions (from procedural abstraction and data abstraction, over defining your own (domain specific) language and implementing a compiler for it to defining new hardware in software). All of it seems so effortless, how only true masters can make things look like.
Make sure you buy the second edition, not the first or more recent ones, however (which use Python instead of Scheme - ugh).
by alabhyajindal on 11/16/24, 7:46 PM
by agumonkey on 11/16/24, 7:18 PM
by debo_ on 11/16/24, 9:30 PM
by anonzzzies on 11/17/24, 8:06 AM
I myself, but probably because I knew and respect the guy, I reread the works of Dijkstra ever so often; books + papers. Not really applicable anymore, but good for the brain and he was a good writer (imho).
by taeric on 11/16/24, 9:12 PM
by myleshenderson on 11/16/24, 8:16 PM
There are things to love about Dr. Racket: hovering over a variable and visually seeing its connections to other places in the code is really cool. But ultimately I was a bit frustrated that it wasn't vs code.
So I stood up an configuration that let me use vs code (cursor actually) to work through the exercises. The LLM integration into cursor is cool as you can give it your code and whatever narrative you wrote and ask for feedback.
I am a tiny way through the exercises but having turned my code, the responses that I write, and the feedback that I get from the LLM into a static site.
It's been a fun way to spend a little time. For sure, I'm not getting the full benefit of working through SICP just with my own thoughts (without the aid of an LLM), but it's neat to see how you can integrate an LLM into the exercise.
by jasonpeacock on 11/16/24, 7:22 PM
Javascript version: https://sourceacademy.org/sicpjs/index
by owl_vision on 11/16/24, 7:52 PM
by jph on 11/16/24, 7:14 PM
If you want to get it elsewhere, the full info is: Structure and interpretation of computer programs by Hal Abelson and Jerry Sussman (MIT Press. 1984. ISBN 0-262-01077-1).
by spit2wind on 11/16/24, 8:19 PM
by Upvoter33 on 11/16/24, 8:09 PM
K&R influenced a generation of programmers.
Hennessy and Patterson influence a generation of architects.
etc. etc.
It's not just SICP.
But the greater point: a book can be meaningful, and we can always use more good ones.
by whobre on 11/16/24, 8:02 PM
by jnordwick on 11/16/24, 10:18 PM
My ta told me that everybody should take the class twice when you first come in and when you're graduating.
When you first take it especially if you know other languages like C at the time you don't get the full depth of the problems you're given a great introduction and you think you understand everything but you don't realize the depth of complexity. Message passing the metacircular evaluator, continuations as the basis of all flow control, etc
You think they are neat tricks that you understand the curriculum because you can do the homework you don't understand how those neat tricks are really the basis of everything else you'll do.
When you're graduating you've had time to go through all your classes you realize just how foundation was principles are and you get so much more out of the book.
Well I didn't take the class a second time I need help grade and TA for a couple semesters.
I work as a quant developer and in trading now and even though my field has nothing to do with that I still think it's the basis of me as a developer.
by munchler on 11/16/24, 7:31 PM
Ironic, given the increasing use of functional programming in domains where old-fashioned imperative/OO programming used to reign alone.
by scop on 11/16/24, 8:33 PM
I am using Elixir’s Livebook to take notes and complete the exercises. It is very helpful to have a live notebook tool while reading it!
by eatonphil on 11/17/24, 3:38 PM
by michelpp on 11/17/24, 4:09 PM
- Godel, Escher, Bach - Hoffstadter
- The Soul of a New Machine - Kidder
- The Emperor's New Mind - Penrose
- The Connection Machine - Hillis
- Algorithmics - Harelby docandrew on 11/16/24, 8:18 PM
by virtuallynathan on 11/17/24, 4:23 AM
by upghost on 11/17/24, 12:41 AM
Why? The modus operandi of problem solving in these books is object oriented programming masquerading as functional programming, and it is presented as a _neutral_ beginner book. It is _not neutral_. This is a very opinionated approach to programming.
To be fair, I do not believe the authors intended for this style of programming to be taken as gospel, but it is often presented _without counterpoint_.
The most powerful technique introduced -- implementing complex behavior via extensible polymorphic generics -- is virtually unmaintainable without a compiler-supported static type checker. You would know that if you ever tried to implement the code yourself in a dynamic language of your choice.
The ramifications of these choices can be felt far and wide and are largely unquestioned.
Ironically, they make code hard to understand, hard to extend, and hard to maintain. I need to reiterate, I do not believe the intention of the authors was to suggest these ideas should be used beyond a pedagogical setting, but they often are.
As a specific critique to SD4F, which states as a goal making code more resilient by emulating biology, I would point to Leslie Lamport's talk on logic vs biology[1].
I would add that I think SICP would be fine if it were taught in tandem with Paradigms of Artificial Intelligence Programming by Peter Norvig[2]. PAIP offers a completely different approach to solving problems, also using lisp. This approach is much closer to constructing a language to model a problem and then solving the problem symbolically using the language created. Areas that use OO techniques, such as the chapter in CLOS, are clearly marked as such.
In other words, I say "SICP considered harmful" because thrusting it upon an eager newcomer as a trusted neutral guide to beginner coding (without offering any counterpoint) could set them back by a decade, filling their head with "functional object oriented programming" concepts that don't translate well to industry or CS.
[*]: I say this as someone who has thoroughly studied both books, implemented the code, taken Dave Beazely courses to have the information spoon fed to me (dabeaz is awesome btw, take all his stuff) and used the techniques in production code bases.
[1]: https://lamport.azurewebsites.net/pubs/future-of-computing.p...
by rongenre on 11/17/24, 4:10 PM
by rurban on 11/17/24, 8:04 AM
by rednafi on 11/16/24, 11:56 PM
I work with distributed systems, writing business logic and dealing with infrastructure concerns. For me, learning about databases, quirks of distributed systems, and patterns for building fault-tolerant services is more important than reading the nth book on structuring programs, deciding which algorithm to use, or figuring out whether my algorithm has O(1) or O(n) complexity.
This doesn’t mean CS fundamentals aren’t important—they are—but I work in a different space. I’d get more value out of reading Designing Data-Intensive Applications than SICP. If I were in the business of building frameworks or databases, I’d probably be the target audience.
by ngcc_hk on 11/18/24, 1:48 AM
We need someone knowing this, just like we need someone to run the nuclear plant we use. But we do not need much those but we need more how to use electricity. Hence unlike another post physics are not the key even if it is more foundational.
For personal growth, it might be still though.
But frankly lisp is such a non-multi-system language, it has a hard time to deal with external world by its nature. It can be done as lisp is really the god level programming language. But as said it is NOT used by the gods for a reason.
We need find a system level language to express ourselves so that we can stand in giants. We need giants but no need to be one.
by Iwan-Zotow on 11/17/24, 2:18 AM
by ingen0s on 11/17/24, 11:40 AM
by Avid_F on 11/17/24, 1:12 AM
by soup10 on 11/17/24, 5:10 AM
by Jiahang on 11/17/24, 1:15 AM
by abeppu on 11/16/24, 7:35 PM
I recall that when MIT stopped teaching with SICP, one of the main claims was that programming now is often not about thinking abstractions through from first principles, and creating some isolated gem of composing definitions. Instead, we interact with and rely on a rich ecosystem of libraries and tools which often have individual quirks and discordant assumptions, and engineering then takes on a flavor of discovering and exploring the properties and limitations of those technologies.
I think now, (some) people also are at the point of not even directly learning about the limitations and capability of each tool in their toolbox, but leaning heavily on generative tools to suggest low-level tactics. I think this will lead to an even messier future, where library code which works on (possibly generated) unit tests will bear some fragile assumption which was never even realized in the head of the engineer that prompted for it, and will not only fail but will be incorporated in training data and generated in the future.
by anon115 on 11/16/24, 10:16 PM
by nomilk on 11/17/24, 4:46 AM
> It's old and feels old. originally in scheme, they recently re released the book in JavaScript which is more approachable to today's audiences and there are still good things in there about encapsulation and building dsls. ymmv. Though the language and programming design concepts hold up, we're playing at higher levels of abstraction on more powerful machines and consequently the examples sometimes seem too tiny and simple.
I had studied economics in a similar way, but learning slightly old/outdated ideas demotivated me - I was much more interested in learning what works and what's considered the best way to do things, not what had been considered a good idea at some point in the past.
I don't want to be a downer on SICP (especially since I haven't even read it), but I hope this info might help others (or elicit a strong refutation).