Oh I love this:
"I use programs as a way of remembering stuff. My memory is the programs I write. If I learn something math or physics or some other maybe biology and I write a program that represent that so I can read the program later it's not ambiguous, easy to read and that way I sort of store my knowledge."
When I was a child I often explored problems using BASIC. It was a really powerful way for me to creatively learn. I tend to think in pictures and find maths hard to truly understand. Coding allows me to create pictures and relationships in my head. I was lucky to find this out when I was young. I'd be lost without it.
Reminds me of my favorite quote from Living Documentation by Cyrille Martraire:
> Software development is all about knowledge and decision-making based on that knowledge, which in turn creates additional knowledge. The given problem, the decision that was made, the reason it was made that way, the facts that led to that decision, and the considered alternatives are all knowledge... each instruction typed in a programming language is a decision... Software design can last a long time. It can last long enough to forget about previous decisions made, as well as their contexts. It can last long enough for people to leave, taking with them their knowledge, and for new people to join, lacking knowledge. Knowledge is central to a design activity like software development. Most of the time this design activity is, for many good reasons, a team effort involving more than one person. Working together means making decisions together or making decisions based on someone else's knowledge. Something unique with software development is that the design involves not only people but also machines... Using a formal language like a programming language, we pass knowledge and decisions to a computer in a form it can understand. Having a computer understand source code is not the hard part... The hardest part is for other people to understand what has been done so that they can then do better and faster work. The greater the ambition, the more documentation becomes necessary to enable a cumulative process of knowledge management that scales beyond what fits in our heads. When our brains and memories are not enough, we need assistance from technologies such as writing, printing, and software to help remember and organize larger sets of knowledge.
I use programming exactly for that, to get rid of ambiguity in notes and make them execut/verifyable. Actually, that was my biggest issue with math: I dont trust myself to make no errors and neither can I trust myself to see them. A compiler/interpreter will make me notice.
I once saw Sussman speak in a group of about 20 neuroscience PhD candidates in an NYU basement. He was talking about AI interpretability long before it was in vougue.
Anyways I asked one question and he immediately sensed there was an EE in the room and went to the side blackboard and showed how we can figure out how an opamp works through first principles.
So much energy and intelligence in that man. Left an impression for sure.
I haven’t watched the video yet, but I was instantly reminded of the Alan J. Perlis quote he and Abelson used for SICP’s dedication:
> I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
I’ve learned that aiming for perfection is how some people have fun. I think the tragedy is when fun, energy, and mental health aren’t part of the conversation about how work gets done.
“We in computer science”! I interpret that as people doing research, not the rest of us who mostly do bean counting programs. For those that pay our salaries, not losing any beans is way more import than how much fun we have, or how much we stretch the possibilities.
I produce my best work at my best productivity when I'm having fun, so those that pay my salary should appreciate that. This is a case where my values and the values of the beancounters are aligned.
If I'm not having fun, then I'm in the wrong position and need to move on. Life is too short to have my day job be a grind, and I won't produce great work in that condition.
I think the act of coding is fun, even if the domain is not.
I think the goal should still be fun. It’s not fun to lose the beans.
I think when the coding becomes overly fearful is when bugs and problems happen. Maybe you don’t have much leeway around the bean part, but you have a lot of room to test and validate that system. How do you make that system as fearless to work with as possible?
It’s a difficult goal, but achieving it is a worthwhile accomplishment. A difficult puzzle that some might find fun.
the sad thing is that the organizations that dont have any fun, that are focussed on the serious, soul crushing business of making sure no beans get dropped, are generally really awful at keeping track of the beans.
"Hey Mr Customer... don't worry that all your data is corrupt or you lost access to your disks ... you have been set in a new direction and we're just making your day job 'fun'"
They're not Bugs ... what you have here are little balls of 'fun' /s
"this is your first step on an incredible journey to fully appreciate how humans ascribe meaning and significance to words they have typed or photographs they have taken..."
A better title: "Academic omputer science is (should be) fun". The main points are that discovering analogies, philosophical contemplation, debugging problems, coming up with good ideas and gaining clarity are all fun activities - but this is mostly the luxury of the academic professor, who is paid to engage in such activities, and doesn't seem applicable to 'the customer wants this at the end of the week!' world, other than the debatable joys of debugging.
The majority of "programming" should probably be thought of like "welding" - essentially a vocational school subject. If you want to develop a new welding technology, sure that's a graduate school-level academic/research undertaking, but the vast majority of welders - like programmers - will work with well-characterized tools and fairly simple systems. A vocational student doesn't want to waste any time learning MIT/GNU Scheme and then never use it again in their professional career - but an academic student might find it rewarding, rather like learning to read and write in Linear B as a linguistics major.
Certainly any work can be 'fun' - I worked in biotech labs for years, some were fun and some were terrible, but that had little to do with the nature of the work - it came down to quality and emotional stability of co-workers and managers, whether the workspace was well-designed and adequately supplied and safe to work in (sloppy labs are dangerous and unhealthy), if the pay was high enough to live a decent life outside of work, whether there was a corporate culture of cutting corners and letting shoddy work slip by (assuming you want to take some pride in doing a job right) - and it's the same in any other professional situation like programming industrial control systems and so on.
Have you ever worked as a welder? I think you'll find that people who are curious, thoughtful, and educated (whether autodidactically or otherwise) do better work than those who aren't across all professions. When I worked as a welder a long time ago the people who were smart, motivated, and curious did better work than those who were just punching a clock.
So I do think that programming is like welding, but not in the way you meant it.
When I think 'welding' I'm thinking of high-tech welding systems, aluminum TIG welding, or the laser-welding assembly-line shop I worked in before going to college. The people running such shops are skilled professionals, certainly, even if they didn't hold graduate degrees in materials science or applied physics.
Maybe your view of welding is that it's comparable to digging ditches? And one doesn't have to go into hundreds of thousands of dollars in debt to attend some exclusive college to be smart, motivated and curious.
Sussman‘s and Abelson‘s SICP forever changed the way I think about code, abstraction, modularity, in a time where my peers were hacking in Pascal or C. Where I used Lisps/Scheme to create a mental model of the problem, they had to do the abstraction in their head and then implement it in a language that demanded low level focus.
So I am forever thankful for having been exposed to SICP early on.
On that note, I find that programming in certain languages is more fun, or can be more comfortable, than in others. I don't think I'll ever be comfortable with C++.
> Great to hear the views on programming from one of the authors of SICP.
I'll blog about it one day (I know it's been five years I've been saying that but hey) but... Sussman invited me for tea in his office so I ran to the MIT co-op but couldn't find SICP there so I told the person there I really needed that book for I'd see Sussman the next day: he called the Harvard co-op and they told me they had one copy in stock. So I uber'ed to the Harvard bookstore and bought SICP.
Next day I went to Sussman's office at the MIT and when I arrived Abelson was there, by chance (he was leaving) so they both dedicated me my copy of SICP. And Sussman added "had you been there 15 minutes earlier my wife would have signed it too!".
I had no idea his wife was the proofreader for SICP.
Fun story. Probably rambling by now but all this really happened. I've got a cool picture of these two wizards and me holding the purple book they just signed!
I coined an AI koan that goes something like this:
A novice travelled to the East to learn at the feet of Sussman. As Sussman lectured on writing device drivers with low-level Lisp code, the novice interrupted: "But Master, is Lisp not a high-level language?" To which Sussman replied: "There was once a fisherman who spotted an eagle on the shore. 'Brother Eagle,' said the fisherman, 'how impossibly distant is the sky!' The eagle said nothing, and flew off." With that, the novice was enlightened.
It's fictional, but it's based on a real-life Sussman encounter I had. A hacker (it may have been Dimitris Vyzovitis) was telling me about things he'd done in "low-level languages like C and Lisp". Then I said "But Lisp is high-level!" at which point the hacker paused and said "Let me get Jerry." "Jerry" turned out to be Gerald Sussman, who explained to me, in the most nerdy-enthusiastic Sussman-like way, that Lisp was the low-level language of a virtual machine which he had actually implemented in hardware[0]. And it was profoundly enlightening.
[0] See Steele, G.L. and Sussman, G.J., AI Memo 514, "Design of LISP-based Processors, or SCHEME: A Dielectric LISP, or Finite Memories Considered Harmful, or LAMBDA: The Ultimate Opcode", https://dspace.mit.edu/handle/1721.1/5731
The book is also so great because it highlights the creative aspect to programming - which they show could (also) be seen as an art form; where it's beyond the utilitarian aspects of coding; appreciating aesthetics / intellectual beauty. All for the sake of instilling in their students a more holistic understanding of the craft while doing so.
IMHO SICP feels "timeless" somewhat because of that.
That is so cool. Watching those SICP lecture videos as a teenager was incredibly formative for me. I still consider myself a knight of the lambda calculus.
I can't wait to watch this.
I haven't gotten to do SICP yet but have it checked out and did get to listen to the classes while doing home renovations.
The Sussman quote from the SICP classes about understanding complicated things makes it in to a lot of my presentations (in architecture of all things) and it's the slide that ALWAYS gets people frantically taking a note.
Readit News
"Programming for the Expression of Ideas"
https://www.infoq.com/presentations/Expression-of-Ideas/
Very adjacent to the quote above. He talks about how programming helps to understand things (mathematics, physics...) in a deeper way.
This bit on mathematical notation and the clarity provided by programming is awesome to see:
"Newtons equation is really a macro, with untyped and undeclared parameters"
- the way pain-killers work tells you a lot about how keyloggers or man-in-the-middle attacks work
- look at how DNA "syntax checking" happens during mitosis to learn about compiling in general
- a puppy swallows whatever it sees; this gives the immune system enough test data about the surroundings etc. (similar to ML)
- a huge amount of cyber-security concepts can be understood by learning biology
> Software development is all about knowledge and decision-making based on that knowledge, which in turn creates additional knowledge. The given problem, the decision that was made, the reason it was made that way, the facts that led to that decision, and the considered alternatives are all knowledge... each instruction typed in a programming language is a decision... Software design can last a long time. It can last long enough to forget about previous decisions made, as well as their contexts. It can last long enough for people to leave, taking with them their knowledge, and for new people to join, lacking knowledge. Knowledge is central to a design activity like software development. Most of the time this design activity is, for many good reasons, a team effort involving more than one person. Working together means making decisions together or making decisions based on someone else's knowledge. Something unique with software development is that the design involves not only people but also machines... Using a formal language like a programming language, we pass knowledge and decisions to a computer in a form it can understand. Having a computer understand source code is not the hard part... The hardest part is for other people to understand what has been done so that they can then do better and faster work. The greater the ambition, the more documentation becomes necessary to enable a cumulative process of knowledge management that scales beyond what fits in our heads. When our brains and memories are not enough, we need assistance from technologies such as writing, printing, and software to help remember and organize larger sets of knowledge.
Anyways I asked one question and he immediately sensed there was an EE in the room and went to the side blackboard and showed how we can figure out how an opamp works through first principles.
So much energy and intelligence in that man. Left an impression for sure.
> I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
If I'm not having fun, then I'm in the wrong position and need to move on. Life is too short to have my day job be a grind, and I won't produce great work in that condition.
I think the goal should still be fun. It’s not fun to lose the beans.
I think when the coding becomes overly fearful is when bugs and problems happen. Maybe you don’t have much leeway around the bean part, but you have a lot of room to test and validate that system. How do you make that system as fearless to work with as possible?
It’s a difficult goal, but achieving it is a worthwhile accomplishment. A difficult puzzle that some might find fun.
"Hey Mr Customer... don't worry that all your data is corrupt or you lost access to your disks ... you have been set in a new direction and we're just making your day job 'fun'"
They're not Bugs ... what you have here are little balls of 'fun' /s
;)
The majority of "programming" should probably be thought of like "welding" - essentially a vocational school subject. If you want to develop a new welding technology, sure that's a graduate school-level academic/research undertaking, but the vast majority of welders - like programmers - will work with well-characterized tools and fairly simple systems. A vocational student doesn't want to waste any time learning MIT/GNU Scheme and then never use it again in their professional career - but an academic student might find it rewarding, rather like learning to read and write in Linear B as a linguistics major.
Certainly any work can be 'fun' - I worked in biotech labs for years, some were fun and some were terrible, but that had little to do with the nature of the work - it came down to quality and emotional stability of co-workers and managers, whether the workspace was well-designed and adequately supplied and safe to work in (sloppy labs are dangerous and unhealthy), if the pay was high enough to live a decent life outside of work, whether there was a corporate culture of cutting corners and letting shoddy work slip by (assuming you want to take some pride in doing a job right) - and it's the same in any other professional situation like programming industrial control systems and so on.
So I do think that programming is like welding, but not in the way you meant it.
Maybe your view of welding is that it's comparable to digging ditches? And one doesn't have to go into hundreds of thousands of dollars in debt to attend some exclusive college to be smart, motivated and curious.
So I am forever thankful for having been exposed to SICP early on.
The anecdotes in the first few mins are nice as well.
I'll blog about it one day (I know it's been five years I've been saying that but hey) but... Sussman invited me for tea in his office so I ran to the MIT co-op but couldn't find SICP there so I told the person there I really needed that book for I'd see Sussman the next day: he called the Harvard co-op and they told me they had one copy in stock. So I uber'ed to the Harvard bookstore and bought SICP.
Next day I went to Sussman's office at the MIT and when I arrived Abelson was there, by chance (he was leaving) so they both dedicated me my copy of SICP. And Sussman added "had you been there 15 minutes earlier my wife would have signed it too!".
I had no idea his wife was the proofreader for SICP.
Fun story. Probably rambling by now but all this really happened. I've got a cool picture of these two wizards and me holding the purple book they just signed!
A novice travelled to the East to learn at the feet of Sussman. As Sussman lectured on writing device drivers with low-level Lisp code, the novice interrupted: "But Master, is Lisp not a high-level language?" To which Sussman replied: "There was once a fisherman who spotted an eagle on the shore. 'Brother Eagle,' said the fisherman, 'how impossibly distant is the sky!' The eagle said nothing, and flew off." With that, the novice was enlightened.
It's fictional, but it's based on a real-life Sussman encounter I had. A hacker (it may have been Dimitris Vyzovitis) was telling me about things he'd done in "low-level languages like C and Lisp". Then I said "But Lisp is high-level!" at which point the hacker paused and said "Let me get Jerry." "Jerry" turned out to be Gerald Sussman, who explained to me, in the most nerdy-enthusiastic Sussman-like way, that Lisp was the low-level language of a virtual machine which he had actually implemented in hardware[0]. And it was profoundly enlightening.
[0] See Steele, G.L. and Sussman, G.J., AI Memo 514, "Design of LISP-based Processors, or SCHEME: A Dielectric LISP, or Finite Memories Considered Harmful, or LAMBDA: The Ultimate Opcode", https://dspace.mit.edu/handle/1721.1/5731
IMHO SICP feels "timeless" somewhat because of that.
The Sussman quote from the SICP classes about understanding complicated things makes it in to a lot of my presentations (in architecture of all things) and it's the slide that ALWAYS gets people frantically taking a note.
> "The key to understanding complicated things is knowing what not to look at, not to compute, not to think" —Sussman.