[Edu-sig] As We May Think: What will we automate?
One of our Wanderers (think tank in Portland) wrote: I expect that teaching Python/Perl/Ruby/Java in the 2000s will be viewed with the same scorn in the 2030's. The problem with flavor of the month languages is that they are passe a month later, as better abstractions appear. Such evanescent ways of doing things are probably not the basis for life-long learning. SNIP In the Wonderful World of the Future, most people will be actively creating active digital content with state and flow control, object abstraction, programming in the sense of producing automated stuff that accomplishes tasks. But it won't be text based. There may be a few Morlocks laboring down amongst the lines of code like you and I do. Working with text code will probably be considered fundamental and connected with our roots, like animal-powered agriculture is now So take a look at programming in schools from the viewpoint of an adult in 2030, not a 2009 viewpoint, and heaven forbid from the viewpoint of the ancient times when you and I were trained. What do you wish you had been taught 40 years ago? What was fashionable but dated? Extrapolate that forwards, and try to guess what they will want, not what you and I consider important /now/. For extra points, try to guess what they should be teaching *their* kids, for use in the year 2060, and get started on the theoretical underpinnings of *that*. I'm wondering what people on this list think about this remark. I responded rather sharply at the time, as I think it's a common dodge, to avoid adding grist to the mill today, because of some hypothetical future wherein said grist will be obsolete. In the meantime, we continue teaching technical subjects as if the FOSS revolution never happened, I think imperiling its gains (sliding back into a pit of deep silos proprietary ignorance -- could happen). I've further registered my disagreement with the above model in my journal posting of this afternoon, but I'm guessing a wider variety of perspectives might be useful at this juncture. http://mybizmo.blogspot.com/2009/03/noodling-and-doodling.html Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] As We May Think: What will we automate?
kirby urner wrote: One of our Wanderers (think tank in Portland) wrote: I expect that teaching Python/Perl/Ruby/Java in the 2000s will be viewed with the same scorn in the 2030's. The problem with flavor of the month languages is that they are passe a month later, as better abstractions appear. Such evanescent ways of doing things are probably not the basis for life-long learning. ... So take a look at programming in schools from the viewpoint of an adult in 2030, not a 2009 viewpoint, and heaven forbid from the viewpoint of the ancient times when you and I were trained. What do you wish you had been taught 40 years ago? What was fashionable but dated? Extrapolate that forwards, and try to guess what they will want, not what you and I consider important /now/. For extra points, try to guess what they should be teaching *their* kids, for use in the year 2060, and get started on the theoretical underpinnings of *that*. To which I'd reply, this is like some reviewer in Chaucer's day saying, Chaucer's writing in Middle English, is such a passing fancy, let's imagine how people will want to use text messages on their cell phones. After all, Prediction is hard, especially about the future. I'll tell you this, in my technical education, I can think of very little that I learned in any of Knuth's classes that is obsolete, and that included working with the MIX computer's machine instruction set. I like the newer machine (a RISC family of instructions) code, as it presents issues from modern architectures more clearly, but getting down all the way to machine code makes you smarter about what is inevitably slow. At the other end, Python gives me a language I can talk to another programmer in, and I can also run parts of the discussion on a machine. There are other languages that do that, of course, but none that are so easily communicated to a random other without spending more time talking about the mechanics than about the idea. I suspect this is why Kirby likes APL so much, he can easily express large-swath ideas. For me, APL too quickly becomes terse little chunks. But Kirby and I program about different things. --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] As We May Think: What will we automate?
At the other end, Python gives me a language I can talk to another programmer in, and I can also run parts of the discussion on a machine. There are other languages that do that, of course, but none that are so easily communicated to a random other without spending more time talking about the mechanics than about the idea. I suspect this is why Kirby likes APL so much, he can easily express large-swath ideas. For me, APL too quickly becomes terse little chunks. But Kirby and I program about different things. --Scott David Daniels scott.dani...@acm.org Yeah, plus when I got involved with APL in 1976-1977, we didn't have Python. This was the first / only language with REPL in my reality, i.e. I could type at a terminal and get an immediate reply, what a difference! Same think people like about Python. My APL is rusty by now, so if someone wants to collaborate with me on communicating some large-swath ideas in at least partly working code, I prefer Python. Like here's some manga code from the PPUG list: http://mail.python.org/pipermail/portland/2009-March/000637.html Thanks for you input Scott. Kirby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] As We May Think: What will we automate?
kirby urner wrote: At the other end, Python gives me a language I can talk to another programmer in, and I can also run parts of the discussion on a machine. There are other languages that do that, of course, but none that are so easily communicated to a random other without spending more time talking about the mechanics than about the idea. I suspect this is why Kirby likes APL so much, he can easily express large-swath ideas. For me, APL too quickly becomes terse little chunks. But Kirby and I program about different things. --Scott David Daniels scott.dani...@acm.org Yeah, plus when I got involved with APL in 1976-1977, we didn't have Python. This was the first / only language with REPL in my reality, i.e. I could type at a terminal and get an immediate reply, what a difference! Same think people like about Python. My APL is rusty by now, so if someone wants to collaborate with me on communicating some large-swath ideas in at least partly working code, I prefer Python. Like here's some manga code from the PPUG list: http://mail.python.org/pipermail/portland/2009-March/000637.html Thanks for you input Scott. Kirby You should definitely take a look at http://arstechnica.com/science/news/2009/03/building-a-better-way-of-understanding-science.ars as this is where Python can be very useful in science -- the stand at a whiteboard and scrawl and argue phases. I do it for computer science, but I've used it to talk evolution with a creationist -- explaining how recognizers can (and are) trained to match things from weighted inputs and evaluate-crossover cycles where the programmer has no idea how to solve the problem, but can train a machine to do so. --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
