10 ms·

The Two Cultures of Computing (2013)

63 points by kercker 10y ago

willtim 10y ago
I'm not sure anyone would be impressed by Python via command line and nano/pico, beginner or otherwise. An interactive notebook with graphics/animations would be the best introduction. Something like this: http://haskellformac.com http://haskellformac.com
- nishac 10y ago
  I agree. I would suggest making simple demos on IPython notebooks.
emodendroket 10y ago
It seems like maybe you'd be better off teaching these users VBA or something.
andrepd 10y ago
I firmly dislike this style of writing. I call it ADD writing. It took 3x as many words to write and 5x as much time to read than if he had just gone straight to the point, instead of going off on some over-the-top rant or irrelevant tangent every other sentence.
- TheOtherHobbes 10y ago
  I agree. This is a superficial and not very original or insightful piece. It doesn't take genius to describe the difference. You can take almost any field - building, architecture, engineering, law - and explain the variation in approach between a user and a professional. Different expectations? Yes Different experience? Yes Different culture? Yes Different skills? Yes Different tools? Yes Why should computing be any different? It worries me that someone who is an associate professor is making such a big deal out of this. He may have a point that students who are used to a GUI are going to have some issues getting used to writing raw code. But it's not as if IDEs don't exist, or that you have to be an expert on the Bash shell to write an iPhone app. I'm really not seeing the problem.
- gavinpc 10y ago
  I really enjoyed the writing style. It was funny throughout, so the length doesn't matter. And it's for a general audience so some cushion is needed.
zekevermillion 10y ago
The problem I see is that it is very difficult to improve user tools when the users (such as myself) are stuck using the wrong abstractions. I'm a corporate lawyer, and the #1 and 2 tools of my trade are Word, followed by Acrobat. Typical process for negotiating a contract is to save new versions in .docx and run "legal compare" in some tool such as DeltaView or Workshare to show change dif between versions. This snapshot dif is then emailed to the people who need to see it. This is a relatively powerful abstraction for a limited field, but is hard to adapt. There is no feedback mechanism between users and developers of these tools. So they basically do not improve, and actually the experience of using them has only gotten worse with time for everyone involved. So the immediate benefit to switching philosophies is zero, though the long-term benefit is huge. But how do you overcome this initial starting friction?
- swalsh 10y ago
  You should try putting the text into git, has all those tools built in... plus a lot more, and no emailing.
  - Jtsummers 10y ago
    Which gets to the post (so I assume this is meant ironically/sarcastically?), steep learning curve of numerous tools. What lawyers (specialists in their field) and others negotiating contracts could use is a subset of git, with better UI. They need version control of the document. They need to know who can edit it at this stage, or who needs to sign off (workflow management). They need to know who did edit it. Systems like this exist that are better than git, some people in the software industry use requirements tracking databases. These are almost literally what's needed once you (often included in them) add on the workflow management: collaborative document editing, ability to view diffs, knowledge of who edited it, restrictions on who may edit it and when, etc. But if it's too small a field, or too disconnected from those of us who can make it, then software like this won't be made or widely used and they'll continue using the functional (but error-prone) method of copy/rename and email.
    - 10y ago
et1337 10y ago
These are not the most compelling tools to begin with. I know how to use Git and markdown, but I still use Google Docs for most things. The key differentiating feature of programming is interactivity, and the most interactive programs are games, which is why they're so great for teaching. You can't make a game with Spotlight search. I always tell people to start with HTML because it gives instant visual feedback, all you need is notepad, and it gets you used to typing words in a text file. Pretty soon they want interactivity, and suddenly they're learning Javascript.
nxc18 10y ago
The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people programming by bombarding them with 50 new tools (git, LaTEX, shells, piping, etc). Yes, those are extremely useful tools for engineers and serious programmers. However, they really aren't necessary or core to programming so much as they are core to engineering, sysadmin-ing, typesetting, etc. To be honest, using LaTEX for your resume is just a bad decision unless you happen to be very good at it and very incompetent with Word. Not only was the author teaching them irrelevant tools, he was stretching them to bizarre use-cases that conflict with how any productive human would approach an everyday task. The essence of programming that needs to be taught is how to think about problems. Those are harder to grasp, but really they are just different ways of thinking. Programmatic thinking is clearly applicable to many things and enriches your life beyond just programming. Throwing tools at people is only important after you've learned how to reason about problems and begin tackling them. Like 1t1337 said, HTML is a good place to start for the basic concept of writing plaintext to control the computer. Beyond that, Python is great for teaching programming as it has an easy, intuitive (relative) syntax and supports many concepts without being too demanding re: types. Don't forget that people new to programming are really new to programming. Just the concepts of int, double, and string can be daunting because people just don't think that way. The biggest challenge I've seen in teaching/coaching new programmers is the concept of assignment vs. equality and how that interacts with variables. Even very smart (young) math majors can get very caught up on the following: number = 5 number = 6 In math (as everyday people understand it), that would clearly be incorrect. I suspect for math-oriented students, functional languages would be a better place to start. I personally learned about programming variables before algebra variables, so my experience was the opposite. I truly believe an excellent introduction to programming course really doesn't even require a computer to be involved, although of course when used correctly computers and live demos add a lot of value. Rather, an excellent course will teach the concepts (variable, typing, what memory is, functions, recursion, iteration, and turning real-world problems into computable problems, and so on) which are completely tool agnostic.
- ScottBurson 10y ago
  Yes, the use of bare "=" for assignment is one of the Great Mistakes of Computing, right up there with null references and zero-terminated strings. There have certainly been languages that have used other operators for assignment, such as ":=" or my own favorite, "<-", but somehow they have never caught on. "=" was good enough for Fortran in 1956, by god -- it's still good enough 60 years later!
gavinpc 10y ago
Apprentice comes into the workshop and the master carpenter performs mysterious steps to make things. Apprentice is baffled by what appears to be difficult and says, "I was wrong about wanting to do this, if this is what it is. I'm going to Ikea, who's with me?" Is it the master's job to persuade the apprentices to stay? This "wait, come back!" reflex is understandable. But even if we could make "conversing" with the computer look easy, it would still be difficult (since, as Alan Turing himself pointed out, anything routine should be automated). Would you feel differently if students were bolting (or merely appalled) when they hit those inevitable, real challenges? I completely agree with the OP that interaction has not fundamentally advanced since the 1960's (edit, well, I'd say 70's, but still). As others have pointed out, the examples could have been better, but it doesn't change the point. Improving interactivity is our problem, especially since we spend the most time with computers. And it's (still) one of the most interesting problems in computing. I would tell students that if you're not satisfied with the state of the art, you're not alone. And if you are satisfied with Ikea, then why are you here? edit moved side comment to a different post.
- coldtea 10y ago
  >Is it the master's job to persuade the apprentices to stay? Not, but it's the master's job to understand that all of his old, hallowed and arcane practices are not necessarily beneficial. Some are just busy-work or cargo-cult. And that because a tool is "tried and true" for decades, it doesn't mean it can't be made better. The command line might be handy for what it does, but from a UX perspective it's a mess. Tons of things that could be done to make it better, and bring it to 2016. Take for example all common UNIX userland programs and change them so that they all respond to the same flags for the same functionality. Here -- instantly better, and we're still in the CLI realm. Or make them understand SIGINFO and turn on verbose mode etc midway. Color-coded output (under a switch) from all tools, not just ls, grep etc. A common configuration format for all of them. There's nothing something like TOML or JSON+comments couldn't handle, instead of each fucking tool having their own bizarro format and parser, resulting in the bloody mess that is /etc/conf. Nor is "man" formatting the best we can do in 2016. I'd even appreciate a "trash mode" for rm as default. Then you do something like "rm purge" and only then it actually kills everything put in between calls. Tons of user documents would have saved that way, instead of "just be careful because that's how we always did things". And of course some --doitnow flag could just delete stuff immediately. Just a few things out of the top of my head. There are tons of other things... Edit: of course those things would never happen, because they require central vision and roadmap, and the unix cli userland is just a set of disparate apps from teams who don't speak to each other. At least FSF could impose some of that roadmap to GNU stuff, but they really don't care, they prefer to pass their time with
pjmlp 10y ago
It is not the programmer culture, rather the UNIX programmer culture. The Mac OS programmer culture before Mac OS X was a thing and Windows programmer cultures, including the Xerox PARC ,Lisp Machines and ETHZ ones, have more to do with user culture than what the author is writing about. I really dislike this hipster idea that the only programmer culture is the UNIX one.
squeaky-clean 10y ago
I don't see any example of the two cultures here. Just an unprepared teacher who chooses bad examples to teach from. The counter-arguments by hypothetical students actually make good points, and I feel are the best ways to solve that certain problem. They know to use the best tools available for their task. The problem is all their tasks are really simple, and the "developer tools" would be a slower solution, or at least not faster. Why do you need to search for all uses of the word 'widget' in python files? Did you write a script, but you forgot the file name and which directory it was in? Any search tool will work for that. Do you want to replace all instance of "widget" with "module" but only within your python scripts? Now the shell commands seem more appropriate. Why can't they just plot a graph with Excel? If you just want to view the line graph from some data points use whatever tool you know best. You can then share that Excel file with anyone else who owns Excel but doesn't understand programming, or export the charts it to a non Excel format I'm sure. But what's that? You want to serve the charts online? Well make them an image and host that. What's that? They need to be dynamic and based on the user? Okay, now we need to code something. What's that again? You just want a chart of some data points for yourself, but you need to compare it against data from an API call? Write something in Python to fetch from that API. You don't know how to use matplotlib? Well output it to a CSV and use Excel for your charting. The "copy, rename, email" is a bit of an ugly system. But it works, especially for simple student projects. Pretty much any undergraduate I've tutored did this (I guess the ones that knew git didn't need tutoring), and it only starts to become a burden when you get to group projects. The other advantage of git, having a logged history of all your changes, possibly spread across branches for different purposes or features, isn't really apparent when your longest homework assignment is a 4 week project. Git is really valuable when you're working on a team, working on something large enough that you can't keep it's history in your head, or you need really quick access to that history ("I just got an alert that our registration page is giving 500 errors after the last update. What did we change?"). I don't see a reason to confuse students who are already trying to understand so many other new things at once. I'm not a professional teacher, so you can take all this with a grain of salt. I think the best way to teach programming is for the students to actually be chasing after something they want to finish. Not just synthetic tasks. No one takes a programming course because "I want to learn Python!". They take it because "I want to make apps / websites / video games / do my math research more easily / automate parts of my job" and so on. And then they're not just learning about loops and control structures because "it's going to be on the exam". They're learning about them because otherwise, your game of blackjack ends after 1 deal, and that's no fun. You really should be able to provide a reason why you're using a certain tool, and not another. Why are you using Python instead of Excel to plot a graph? You're just faster with Python? That's a valid reason. But "because my professor is faster with Python" is not.
sbierwagen 10y ago
The purpose of programming is to do things at scale, to automate them. Writing a one-off Python script to search for the string "widget" is insane when Spotlight exists. But a script that performs searches is useful when you need to search for a thousand strings. Using the Imagemagick CLI to resize a single image is ridiculously cumbersome when Photoshop exists, but vastly more useful when you need to resize a folder with 50,000 jpegs in it. The reason newbies question the usefulness of trivial examples is because they're trivial problems. Programmer tools are only useful for big problems.
yusee 10y ago
If programming were easier, why would coders make six figs? Doctors and lawyers have regulatory bodies that protect them. We just make make our jobs too frustrating for non-nerds.

63 points by kercker 10y ago

I'm not sure anyone would be impressed by Python via command line and nano/pico, beginner or otherwise. An interactive notebook with graphics/animations would be the best introduction. Something like this: http://haskellformac.com http://haskellformac.com

nishac 10y ago
I agree. I would suggest making simple demos on IPython notebooks.

emodendroket 10y ago

It seems like maybe you'd be better off teaching these users VBA or something.

andrepd 10y ago

I firmly dislike this style of writing. I call it ADD writing. It took 3x as many words to write and 5x as much time to read than if he had just gone straight to the point, instead of going off on some over-the-top rant or irrelevant tangent every other sentence.

TheOtherHobbes 10y ago
I agree. This is a superficial and not very original or insightful piece. It doesn't take genius to describe the difference. You can take almost any field - building, architecture, engineering, law - and explain the variation in approach between a user and a professional. Different expectations? Yes Different experience? Yes Different culture? Yes Different skills? Yes Different tools? Yes Why should computing be any different? It worries me that someone who is an associate professor is making such a big deal out of this. He may have a point that students who are used to a GUI are going to have some issues getting used to writing raw code. But it's not as if IDEs don't exist, or that you have to be an expert on the Bash shell to write an iPhone app. I'm really not seeing the problem.
gavinpc 10y ago
I really enjoyed the writing style. It was funny throughout, so the length doesn't matter. And it's for a general audience so some cushion is needed.

zekevermillion 10y ago

The problem I see is that it is very difficult to improve user tools when the users (such as myself) are stuck using the wrong abstractions. I'm a corporate lawyer, and the #1 and 2 tools of my trade are Word, followed by Acrobat. Typical process for negotiating a contract is to save new versions in .docx and run "legal compare" in some tool such as DeltaView or Workshare to show change dif between versions. This snapshot dif is then emailed to the people who need to see it. This is a relatively powerful abstraction for a limited field, but is hard to adapt. There is no feedback mechanism between users and developers of these tools. So they basically do not improve, and actually the experience of using them has only gotten worse with time for everyone involved. So the immediate benefit to switching philosophies is zero, though the long-term benefit is huge. But how do you overcome this initial starting friction?

swalsh 10y ago
You should try putting the text into git, has all those tools built in... plus a lot more, and no emailing.
- Jtsummers 10y ago
  Which gets to the post (so I assume this is meant ironically/sarcastically?), steep learning curve of numerous tools. What lawyers (specialists in their field) and others negotiating contracts could use is a subset of git, with better UI. They need version control of the document. They need to know who can edit it at this stage, or who needs to sign off (workflow management). They need to know who did edit it. Systems like this exist that are better than git, some people in the software industry use requirements tracking databases. These are almost literally what's needed once you (often included in them) add on the workflow management: collaborative document editing, ability to view diffs, knowledge of who edited it, restrictions on who may edit it and when, etc. But if it's too small a field, or too disconnected from those of us who can make it, then software like this won't be made or widely used and they'll continue using the functional (but error-prone) method of copy/rename and email.
  - 10y ago

et1337 10y ago

These are not the most compelling tools to begin with. I know how to use Git and markdown, but I still use Google Docs for most things. The key differentiating feature of programming is interactivity, and the most interactive programs are games, which is why they're so great for teaching. You can't make a game with Spotlight search. I always tell people to start with HTML because it gives instant visual feedback, all you need is notepad, and it gets you used to typing words in a text file. Pretty soon they want interactivity, and suddenly they're learning Javascript.

nxc18 10y ago

The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people programming by bombarding them with 50 new tools (git, LaTEX, shells, piping, etc). Yes, those are extremely useful tools for engineers and serious programmers. However, they really aren't necessary or core to programming so much as they are core to engineering, sysadmin-ing, typesetting, etc. To be honest, using LaTEX for your resume is just a bad decision unless you happen to be very good at it and very incompetent with Word. Not only was the author teaching them irrelevant tools, he was stretching them to bizarre use-cases that conflict with how any productive human would approach an everyday task. The essence of programming that needs to be taught is how to think about problems. Those are harder to grasp, but really they are just different ways of thinking. Programmatic thinking is clearly applicable to many things and enriches your life beyond just programming. Throwing tools at people is only important after you've learned how to reason about problems and begin tackling them. Like 1t1337 said, HTML is a good place to start for the basic concept of writing plaintext to control the computer. Beyond that, Python is great for teaching programming as it has an easy, intuitive (relative) syntax and supports many concepts without being too demanding re: types. Don't forget that people new to programming are really new to programming. Just the concepts of int, double, and string can be daunting because people just don't think that way. The biggest challenge I've seen in teaching/coaching new programmers is the concept of assignment vs. equality and how that interacts with variables. Even very smart (young) math majors can get very caught up on the following: number = 5 number = 6 In math (as everyday people understand it), that would clearly be incorrect. I suspect for math-oriented students, functional languages would be a better place to start. I personally learned about programming variables before algebra variables, so my experience was the opposite. I truly believe an excellent introduction to programming course really doesn't even require a computer to be involved, although of course when used correctly computers and live demos add a lot of value. Rather, an excellent course will teach the concepts (variable, typing, what memory is, functions, recursion, iteration, and turning real-world problems into computable problems, and so on) which are completely tool agnostic.

ScottBurson 10y ago
Yes, the use of bare "=" for assignment is one of the Great Mistakes of Computing, right up there with null references and zero-terminated strings. There have certainly been languages that have used other operators for assignment, such as ":=" or my own favorite, "<-", but somehow they have never caught on. "=" was good enough for Fortran in 1956, by god -- it's still good enough 60 years later!

gavinpc 10y ago

Apprentice comes into the workshop and the master carpenter performs mysterious steps to make things. Apprentice is baffled by what appears to be difficult and says, "I was wrong about wanting to do this, if this is what it is. I'm going to Ikea, who's with me?" Is it the master's job to persuade the apprentices to stay? This "wait, come back!" reflex is understandable. But even if we could make "conversing" with the computer look easy, it would still be difficult (since, as Alan Turing himself pointed out, anything routine should be automated). Would you feel differently if students were bolting (or merely appalled) when they hit those inevitable, real challenges? I completely agree with the OP that interaction has not fundamentally advanced since the 1960's (edit, well, I'd say 70's, but still). As others have pointed out, the examples could have been better, but it doesn't change the point. Improving interactivity is our problem, especially since we spend the most time with computers. And it's (still) one of the most interesting problems in computing. I would tell students that if you're not satisfied with the state of the art, you're not alone. And if you are satisfied with Ikea, then why are you here? edit moved side comment to a different post.

coldtea 10y ago
>Is it the master's job to persuade the apprentices to stay? Not, but it's the master's job to understand that all of his old, hallowed and arcane practices are not necessarily beneficial. Some are just busy-work or cargo-cult. And that because a tool is "tried and true" for decades, it doesn't mean it can't be made better. The command line might be handy for what it does, but from a UX perspective it's a mess. Tons of things that could be done to make it better, and bring it to 2016. Take for example all common UNIX userland programs and change them so that they all respond to the same flags for the same functionality. Here -- instantly better, and we're still in the CLI realm. Or make them understand SIGINFO and turn on verbose mode etc midway. Color-coded output (under a switch) from all tools, not just ls, grep etc. A common configuration format for all of them. There's nothing something like TOML or JSON+comments couldn't handle, instead of each fucking tool having their own bizarro format and parser, resulting in the bloody mess that is /etc/conf. Nor is "man" formatting the best we can do in 2016. I'd even appreciate a "trash mode" for rm as default. Then you do something like "rm purge" and only then it actually kills everything put in between calls. Tons of user documents would have saved that way, instead of "just be careful because that's how we always did things". And of course some --doitnow flag could just delete stuff immediately. Just a few things out of the top of my head. There are tons of other things... Edit: of course those things would never happen, because they require central vision and roadmap, and the unix cli userland is just a set of disparate apps from teams who don't speak to each other. At least FSF could impose some of that roadmap to GNU stuff, but they really don't care, they prefer to pass their time with

pjmlp 10y ago

It is not the programmer culture, rather the UNIX programmer culture. The Mac OS programmer culture before Mac OS X was a thing and Windows programmer cultures, including the Xerox PARC ,Lisp Machines and ETHZ ones, have more to do with user culture than what the author is writing about. I really dislike this hipster idea that the only programmer culture is the UNIX one.

squeaky-clean 10y ago

I don't see any example of the two cultures here. Just an unprepared teacher who chooses bad examples to teach from. The counter-arguments by hypothetical students actually make good points, and I feel are the best ways to solve that certain problem. They know to use the best tools available for their task. The problem is all their tasks are really simple, and the "developer tools" would be a slower solution, or at least not faster. Why do you need to search for all uses of the word 'widget' in python files? Did you write a script, but you forgot the file name and which directory it was in? Any search tool will work for that. Do you want to replace all instance of "widget" with "module" but only within your python scripts? Now the shell commands seem more appropriate. Why can't they just plot a graph with Excel? If you just want to view the line graph from some data points use whatever tool you know best. You can then share that Excel file with anyone else who owns Excel but doesn't understand programming, or export the charts it to a non Excel format I'm sure. But what's that? You want to serve the charts online? Well make them an image and host that. What's that? They need to be dynamic and based on the user? Okay, now we need to code something. What's that again? You just want a chart of some data points for yourself, but you need to compare it against data from an API call? Write something in Python to fetch from that API. You don't know how to use matplotlib? Well output it to a CSV and use Excel for your charting. The "copy, rename, email" is a bit of an ugly system. But it works, especially for simple student projects. Pretty much any undergraduate I've tutored did this (I guess the ones that knew git didn't need tutoring), and it only starts to become a burden when you get to group projects. The other advantage of git, having a logged history of all your changes, possibly spread across branches for different purposes or features, isn't really apparent when your longest homework assignment is a 4 week project. Git is really valuable when you're working on a team, working on something large enough that you can't keep it's history in your head, or you need really quick access to that history ("I just got an alert that our registration page is giving 500 errors after the last update. What did we change?"). I don't see a reason to confuse students who are already trying to understand so many other new things at once. I'm not a professional teacher, so you can take all this with a grain of salt. I think the best way to teach programming is for the students to actually be chasing after something they want to finish. Not just synthetic tasks. No one takes a programming course because "I want to learn Python!". They take it because "I want to make apps / websites / video games / do my math research more easily / automate parts of my job" and so on. And then they're not just learning about loops and control structures because "it's going to be on the exam". They're learning about them because otherwise, your game of blackjack ends after 1 deal, and that's no fun. You really should be able to provide a reason why you're using a certain tool, and not another. Why are you using Python instead of Excel to plot a graph? You're just faster with Python? That's a valid reason. But "because my professor is faster with Python" is not.

sbierwagen 10y ago

The purpose of programming is to do things at scale, to automate them. Writing a one-off Python script to search for the string "widget" is insane when Spotlight exists. But a script that performs searches is useful when you need to search for a thousand strings. Using the Imagemagick CLI to resize a single image is ridiculously cumbersome when Photoshop exists, but vastly more useful when you need to resize a folder with 50,000 jpegs in it. The reason newbies question the usefulness of trivial examples is because they're trivial problems. Programmer tools are only useful for big problems.

yusee 10y ago

If programming were easier, why would coders make six figs? Doctors and lawyers have regulatory bodies that protect them. We just make make our jobs too frustrating for non-nerds.