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.
You’re describing nothing more than having the programmer be able to stay in the “fun/challenging” zone, above the “boring” zone and below the “stressful/helpless” zone. This is obviously very personal: What is boring for you may be challenging for me. Further, all learners of any subject are trying to stay in this zone. Professional educators are very aware of this and refer to it broadly as “student engagement”.
The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
> The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
Sure. It’s my goal. Not my project’s. My project doesn’t care about anything really.
The name of the game for me (the programmer) is maximizing my output without getting burned out. To that end, my intermediate goal is to find fun where I can. That’s the game.
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.
Maybe I misunderstood, I was responding to your characterization of welding as a "vocational school subject" whose future practitioners wouldn't want to waste their time learning anything that isn't the direct application of various welding processes to their first job in the field. In fact, though, folks who are the best at actually doing the welding are those who are most interested in developing their craft as welders--whatever that takes be it attaining theoretical knowledge, experimenting with obsolete or rarely used processes (e.g forge welding), etc.
Analogously, computerers who are best at computering aren't the ones who just want to learn enough jquery to get that computer gig.
So what's the point of education? Is it to illuminate the path to excellence for those who choose to follow it, or is it to try to land someone a job and no other thing?
Ideally, people with the intellectual capability to get into MIT wouldn't have to go into massive debt that would drastically curtail their future choices in life, which is what higher education has sadly meant for many people:
> "To attend Massachusetts Institute of Technology for four years, the cost, based on 2022-23 numbers, would be $319,400, including tuition and fees, books, and room and board."
Yeah, that's completely messed up. And probably completely unnecessary, given the income from their endowment. OTOH, someone who can get into MIT can probably also get into a university in a civilized country that doesn't view education as a profit center.
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.
I spent my life looking for such an elegant tome. If I had discovered it when I was 15 maybe my life would have been happier.
Utilitarian programming is like utilitarian food. Programming should be seen as an act of worship to the god of simplicity. If the artificial world intrudes and makes the program complicated, this is what leads to suffering. Ultimately it is the world which should be changed.
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.
I can't lie, I loved programming for many years. It used to be my main hobby too. Trying any new language or software, reading programming books, contributing to many chats across libera/freenode and what not.
But since I have become a freelancer and I started working in smaller contexts where the focus is to ship decent code at a higher rate this passion has vaned. I think this is overall good for me as an engineer, but has removed lots of fun and often learning from my daily job.
that probably has more to do with freelancing and consulting in general, rather than something inherit in programming
freelancing and consulting, is usually about problem solving, and even problem shooting (get rid of the problem as soon as possible, elegance not required)
you want to be a builder a tool maker, with freelancing, i dont see this happening, if you move to a consultant role maybe
for me consultant are a bit more into longer term relationship , so maybe this should be your next step
Coding is fun. When you have Stuff to Do, and momentum and a clear path to do it.
You have a ditch to dig and you just get into it.
Stack of simple web pages to knock out. Bunch of business rules to code up. Couple of routine CRUD screens.
Architecting is fun. Whiteboard, pens, couple folks in the same groove around the table. Sussing it out. Waving off the 0.01% edge case “what ifs”.
Fighting frameworks? Fighting tools? Wiring together badly behaving black boxes?
That’s not fun.
Neck deep in bad documentation. Heated discussions talking past each other on a forum. Negotiating with the dumber than rocks AI that had a flash of competence.
I like to say if I wanted to wire together badly documented black boxes, I’d have become an EE.
I’ve always said: “I love programming, but I hate computers.” All the fiddling. Software going stupid. Updates frustrating new UX. “Honey, the printer isn’t working.”
>I like to say if I wanted to wire together badly documented black boxes, I’d have become an EE.
I like to say that Electrical Engineers don't believe in magic; Computer Scientists don't believe in physics!
I worked for Gerry making software for 6.002x an experimental intro EE class. I remember when Gerry came back from a weekend with a whole constraint propagator coded up!
Feynman called it the computer disease.
I think that is understudied danger of computers - addictive play/fidget machines that stunt intellectual and personal growth.
What all the "not fun" stuff you're referring to has in common, is extraneous complexity.
We don't pick a framework so that we can spend hours trying to figure out why our model of what it does is different from what it actually does. We run ./configure so we can run make, not so we can spend time determining why running autoconf results in the functionality we're expecting to use getting stubbed out.
And so on. The amount of time we have to spend on things which aren't the problem can grow arbitrarily large. Manifesting a solution to the actual problem, with all of its intrinsic complexity, that is fun.
Agree! But, coding is not (all of) software development. Said another way, maybe some people like the idea of software development more than they actually like software development.
> Fighting frameworks? Fighting tools? Wiring together badly behaving black boxes?
> That’s not fun.
<popular cloud platform> makes me want to shoot myself in the face.
How did we get to this point? What the fuck? Did people just need a lot of busy work to make themselves feel productive???
No. Not any more. Programming should be as dull as operating a sawmill.
I knew a guy, his construction company built half of Lake Tahoe back in the day. When he retired he built himself a work shop in the basement and made furniture until the day he died. It's incredible furniture. I'm sitting at one of his desks, on one of his chairs. 40 years old and still in excellent condition, and beautiful! Helical legs. You cannot buy furniture like this in the store. Handmade by a master craftsman at the height of his skill and knowledge. Made solely for the love of the craft and the joy of giving gifts.
That kind of person has fun working.
Computer programming IS fun to the kind of person who enjoys computer programming. Those people can do what they like.
The rest of us want "boring" software: machines that get the job done, that don't break, that don't spew private data into the cloud willy-nilly, etc.
If making that kind of software isn't intrinsically fun for you then maybe don't be a computer programmer? (We made a huge mistake making the normals think that learning a bit of JS was a viable career path.)
Industrial software shouldn't be fun (except of course to the people who already find it fun to deliver solid working software!)
- - - -
In re: bugs being fun little learning opportunities...
Margaret Hamilton worked out how to write bug-free software during the Apollo 11 project. The IT industry collectively went, "meh."
Corrollary: people who build bridges don't think it's fun when bridges collapse, but bridge builders have had millenia of accumulated experience that inform the codes and practices of bridge building.
That's what we lack in software. If you do electrical work that isn't up to code, you as the electrician are liable. That means literally that if you touch a system, and you were the last one to touch it, you're liable. So it better be up to code when you're done.
> Margaret Hamilton worked out how to write bug-free software during the Apollo 11 project. The IT industry collectively went, "meh."
I have tried to look into this before, and I never can find much information about it. Last I checked, her homepage was basically trying to sell some proprietary system to customers who have bought into her marketing about "bug-free software". But actually trying to figure out how it works, or how to do it oneself, has remained elusive. Saying "The IT industry collectively went, 'meh.'" is kind of misleading. It's not exactly clear _what_ she worked out, but I'm skeptical of the claim that she "worked out how to write bug-free software". And if she did, she isn't exactly shouting from the rooftops about how to do it.
> Margaret Hamilton worked out how to write bug-free software during the Apollo 11 project. The IT industry collectively went, "meh."
That's an often repeated myth but it collapses the moment one digs a bit further (rather than swallowing preposterous statements). She was a glorified manager at best, others did the programming that actually mattered.
Hal Laning [2] was primarily responsible for what Hamilton gets credit for.
Yeah this sort of after-the-fact character assassination is BS. People get jealous of other people's fame. One publicity photo and a little fame and you've got whole threads of folks tearing you down, "she was /just/ the team leader". Whatever.
I think it's a reasoning like "math is fun", but for some people math is useless until become useful in some sense. Programming is something similar in that regard.
For the problems I like, programming is fun, for those I don't like, I prefer only get shit done too (like part of my job).
That's not accurate. They retired SICP and added a new introductory course [1] based on Python to placate the suits. Neither Sussman nor any of the other SICP folk is involved with that.
Sussman created a follow-up course to SICP [2] which is still based on Lisp and still being offered today.
I don't think the new course is "SICP with Python"; my impression (from talking to GJS!) is it's a different course that now uses Python. But maybe someone here has experience with it & can speak up.
This is missing the forest for the trees. The language for a university course in computation needn't be "commercially relevant". What's important is whether it serves the pedagogical purpose of teaching students to think about computation.
Learning this or that programming language isn't at all what it's about--you can (and will over and over again throughout your career) do that on your own time. It's about developing the abstract thought pathways that enable you to quickly learn and think about computing.
I don't know why MIT chose to stop teaching the course, but it sure would lower my opinion of that institution if it was something to do with the direct commercial appeal of "knowing Python".
This presentation seem to be mostly about the community aspects of Raku in how they made the language approachable. Is there a presentation that focuses more on the technical aspects of how Raku's syntax and libraries would make it more fun relative to Perl or Ruby?
The presentation is about a few different topics related to learning Raku, IIRC, such as books and docs for learning it, community, code of conduct, etc.
After watching the full video, I agree that the title could be more descriptive of the content.
You can check out these videos, they may be something like what you are looking for:
Raku: The Programming Language You Didn't Know You Needed
To me, I always feel this disconnect when people from academia talk about programming. I guess this is just me because of my personal experiences as a coder though, andothers don't have this.
Hm. I feel it differently. As a software engineering entrepreneur for some decades, I feel keenly the urgency of getting features implemented, bugs fixed, and teams motivated. It is usually a grind.
But when I want to feel a spiritual connection to the fundamental principles of my work effort, academia is one of several places I turn to.
The news of Lynn Conway's death hit me hard because I learned a lot from her but I never got to meet her and thank her.
I learned a lot from Sussman too and I'm very glad I've gotten the chance to buttonhole him in the hallway several times and ask him a question and let him talk. I always learn something much more interesting than the answer to my original question.
I highly recommend stopping by and saying hi to Sussman if you find yourself at CSAIL.
The Software Industry needs to take notes from this. They are the ones who have beaten the fun out of Programming and turned it into a drudgery/chore and have caused many Programmers who loved their craft to quit the field entirely. It is possible to meet customer/business needs and still create/maintain a work environment where the programming activity itself is fun for the developers. The way to do it is to abandon Taylorism Management and approach Software Development as a "Human-first" activity akin to that of a poet/painter/artist. Promote Autonomy, challenges compatible with competence, encourage novelty/learning/training and focus less on schedules, micromanagement and detailed processes.
Anecdotally, programmer colleagues that view themselves as artists are generally harder to work with than those that identifies as craftsmen. It's generally much easier to have a sound argument about someone's work if they don't view it as their art.
"Craft" is very much an emotional identity and art form, and for many people craft is fun as well - maybe not the exact same emotion, but for me craft is the quiet kind of fun.
I identify as a craftsman but I resonate with the above comment.
Ultimately programming is half technical (what does the computer do) and half human expression (reading and writing code).
The latter [0] is really more of an art than a science or an engineering discipline. Look at all the attempts to prove that one particular way of writing programs is more productive, comprehensible or maintainable than others. They all failed in unique ways, perhaps because human communication is highly complex and contextual. The only thing we all might agree on is "consistency is good".
[0] The former is in my opinion generally overlooked in many fields, even though it's the most measurable. But it is apparently often in conflict with with the latter unfortunately.
Second that. I have been in the industry for 37 years. The Taylorism didn't exist until "Agile" came along around the year 2000. Every programmer was a craftsman before that.
These days, I wouldn't take (or get)a job in most software companies. I suspect that in quite a few non software companies there are software craftspeople working away quietly.
> The Taylorism didn't exist until "Agile" came along around the year 2000.
There was plenty of that before 2000, but it was more in the mainframe world. "Data processing". Government contracts. Business applications. "Software analysts" who broke the problem down into small chunks, and gave those to programmers.
I have been in the industry for 39 years, and I avoided almost all of that, but it was there...
> The Taylorism didn't exist until "Agile" came along around the year 2000.
Its widespread adoption (and usually counter to the spirit of the original Manifest itself) took years however — years where most places, the craftfulness was still prevalent. Myself I haven't encountered that in teams until the mid-2010s, less than a decade ago. Might have been earlier in SV, of course, though. And the bigger Java/.NET/Enterprise shops.
