I really liked this article. As someone who works in tech and has always been interested in the field as a hobby, I never had any real acculturation into the world of software so many of these...
I really liked this article. As someone who works in tech and has always been interested in the field as a hobby, I never had any real acculturation into the world of software so many of these axioms were new to me, particularly the bit about code being intended for people instead of for machine execution. I always kind of had this in mind. Since my limited programming background was confined to doing statistical research, I was always focused on readability since I approached whatever code I read like a lab notebook that was supposed to be saved for posterity. But once I moved into tech I always felt a bit like an odd duck, fussing over clear commenting and being preoccupied with methods and being able to retrace our steps. It puts me very out of step with a coding culture focused on SPRINT! DEMO! SHIP! at as breakneck a pace as is sustainable.
This part isn't new, but it's been of particular concern for me:
What happens when we rely on these models to produce new realities, and feed those slightly-wrong realities back into the machines again? What happens when we listen to Spotify’s Discover Weekly playlist week after week, “like” the posts that Facebook recommends to us, and scroll through TikTok after TikTok? I am guilty of all of these, and it would not be wrong to claim that my taste in music and sense of humor are mediated by this mutual recursion between the algorithms and the real world.
I think I mentioned this on a "What has been an "I told you so" moment since the lockdown?" thread a few months ago. I was on a sales call with these guys from Exabeam where they were touting their machine learning modeling as a way of profiling 'normal behavior' and alerting my clients' SOC whenever someone deviated. I asked what happens if the way people do business changes quickly and your training data all ends up being junk? Then a month later, the way everyone does business changed VERY quickly.
But this isn't even just a software thing, it's kind of endemic in any business strategy that works according to a define process -> do stuff -> get data -> refine process -> do stuff -> get data -> refine. . . You're only actually engaging with the theoretical underpinnings in the beginning, when you're defining your process. That ends up being the only time you're thinking about the limitations of your model. After that it's a purely data driven loop with no theory behind it, and the data is inherently limited in validity when you generalize your use cases. In finance this is known as reflexivity, but most executives just don't seem to get it and don't understand how to grapple with the problem.
I had this argument with a campaign manager for a local candidate for Congress. I asked about why they were doing so much spend on TV ad buys knowing the key to election was going to be youth and minority turnout, which doesn't respond to those ad buys. She said she wishes they could do the outreach more, but the data showed that ROI on TV spending far far outstripped all other forms of outreach. I tried to explain that if you ignore that target demo year after year, they're not primed to respond to future ads and the reason TV ads seem to have higher ROI is because you've conditioned that cohort that watches TV to vote over years of training. You need to actually put in that front-end investment to get people engaged. She agreed, it sounded like she believed me, but when you're 3 months away from an election it was already too late to do anything about it and, besides, it's not like you can convince someone to make big strategic decisions without DATA to back it.
So really, it's not just that software went wrong. The world kind of went wrong when we decided we could make big decisions on purely technical analysis without understanding, or even caring about understanding fundamentals.
This notion of addressability and writing software for people is so fuzzy it obscures more than it reveals. The authors of Structure and Interpretation of Computer Programs were talking about the...
This notion of addressability and writing software for people is so fuzzy it obscures more than it reveals. The authors of Structure and Interpretation of Computer Programs were talking about the readability of source code. This has nothing to do with how malware works.
Nowadays we are used to multi-user software and the terrible emergent problems of social usage, but at the time that book was written, software was often single-user. I don't remember any of the programs in the book connecting to a network and they didn't write about the security issues from using the software either. It was about writing scheme programs to do math and simulations, and about people writing software for their own use and to share with other people who wanted to do calculations. A simpler world.
This article commits a common sin of humanities writing of bringing up one thing after another without saying much about any single subject, relying on gestures in the direction of complexity to sound deep. For example, what does it really say about npm and the problems of package management? Package management is unlike more primitive forms of code sharing (such as copy-paste) due to semi-automatic updates. It's not "how we have always programmed." The specifics of how we build on other people's work matter because they create new problems to solve.
The unreadability of obfuscated code, and the readability of "well written" code are two sides of the same coin. If that were not the case, then malware authors would not have to bother with all...
The authors of Structure and Interpretation of Computer Programs were talking about the readability of source code. This has nothing to do with how malware works.
The unreadability of obfuscated code, and the readability of "well written" code are two sides of the same coin. If that were not the case, then malware authors would not have to bother with all the effort of obfuscating their code. The cat and mouse game between the malware author and the security analyst is a dialogue.
I don't remember any of the programs in the book connecting to a network and they didn't write about the security issues from using the software either.
I think there's still value in applying the ideas from SICP to our complicated, networked world, even if the book wasn't written in that context. If we only thought within the confines of our sources, then we would never create anything new :)
It's a very different dialog from sharing source code collaboratively. Saying that two unrelated things are both dialogs is just surface similarity. Like, okay, we can use the same word. So what?
It's a very different dialog from sharing source code collaboratively. Saying that two unrelated things are both dialogs is just surface similarity. Like, okay, we can use the same word. So what?
I really liked this article. As someone who works in tech and has always been interested in the field as a hobby, I never had any real acculturation into the world of software so many of these axioms were new to me, particularly the bit about code being intended for people instead of for machine execution. I always kind of had this in mind. Since my limited programming background was confined to doing statistical research, I was always focused on readability since I approached whatever code I read like a lab notebook that was supposed to be saved for posterity. But once I moved into tech I always felt a bit like an odd duck, fussing over clear commenting and being preoccupied with methods and being able to retrace our steps. It puts me very out of step with a coding culture focused on SPRINT! DEMO! SHIP! at as breakneck a pace as is sustainable.
This part isn't new, but it's been of particular concern for me:
I think I mentioned this on a "What has been an "I told you so" moment since the lockdown?" thread a few months ago. I was on a sales call with these guys from Exabeam where they were touting their machine learning modeling as a way of profiling 'normal behavior' and alerting my clients' SOC whenever someone deviated. I asked what happens if the way people do business changes quickly and your training data all ends up being junk? Then a month later, the way everyone does business changed VERY quickly.
But this isn't even just a software thing, it's kind of endemic in any business strategy that works according to a define process -> do stuff -> get data -> refine process -> do stuff -> get data -> refine. . . You're only actually engaging with the theoretical underpinnings in the beginning, when you're defining your process. That ends up being the only time you're thinking about the limitations of your model. After that it's a purely data driven loop with no theory behind it, and the data is inherently limited in validity when you generalize your use cases. In finance this is known as reflexivity, but most executives just don't seem to get it and don't understand how to grapple with the problem.
I had this argument with a campaign manager for a local candidate for Congress. I asked about why they were doing so much spend on TV ad buys knowing the key to election was going to be youth and minority turnout, which doesn't respond to those ad buys. She said she wishes they could do the outreach more, but the data showed that ROI on TV spending far far outstripped all other forms of outreach. I tried to explain that if you ignore that target demo year after year, they're not primed to respond to future ads and the reason TV ads seem to have higher ROI is because you've conditioned that cohort that watches TV to vote over years of training. You need to actually put in that front-end investment to get people engaged. She agreed, it sounded like she believed me, but when you're 3 months away from an election it was already too late to do anything about it and, besides, it's not like you can convince someone to make big strategic decisions without DATA to back it.
So really, it's not just that software went wrong. The world kind of went wrong when we decided we could make big decisions on purely technical analysis without understanding, or even caring about understanding fundamentals.
This notion of addressability and writing software for people is so fuzzy it obscures more than it reveals. The authors of Structure and Interpretation of Computer Programs were talking about the readability of source code. This has nothing to do with how malware works.
Nowadays we are used to multi-user software and the terrible emergent problems of social usage, but at the time that book was written, software was often single-user. I don't remember any of the programs in the book connecting to a network and they didn't write about the security issues from using the software either. It was about writing scheme programs to do math and simulations, and about people writing software for their own use and to share with other people who wanted to do calculations. A simpler world.
This article commits a common sin of humanities writing of bringing up one thing after another without saying much about any single subject, relying on gestures in the direction of complexity to sound deep. For example, what does it really say about npm and the problems of package management? Package management is unlike more primitive forms of code sharing (such as copy-paste) due to semi-automatic updates. It's not "how we have always programmed." The specifics of how we build on other people's work matter because they create new problems to solve.
The unreadability of obfuscated code, and the readability of "well written" code are two sides of the same coin. If that were not the case, then malware authors would not have to bother with all the effort of obfuscating their code. The cat and mouse game between the malware author and the security analyst is a dialogue.
I think there's still value in applying the ideas from SICP to our complicated, networked world, even if the book wasn't written in that context. If we only thought within the confines of our sources, then we would never create anything new :)
It's a very different dialog from sharing source code collaboratively. Saying that two unrelated things are both dialogs is just surface similarity. Like, okay, we can use the same word. So what?