Follow-up post explaining research rationale

Ryan Frame via Digitalmars-d digitalmars-d at puremagic.com
Sun May 15 15:40:40 PDT 2016


On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
> I don't think the platforms people are introduced to in CS 
> education are very good at generating excitement about what 
> computers can do. It would be interesting to gauge what sorts 
> of things people think they might be able to create, what sorts 
> of problems they think they could solve, or new interfaces they 
> could implement, after their introduction to programming. What 
> horizons do they see?

I think you're partly right here, but you seem to think somebody 
can read a "Learn [language] in 24 Hours" book and write awesome 
software; that isn't going to happen. Programming is a craft. I 
play classical guitar as a hobby, but I have a friend that 
embodies classical music. I can play, but because of his 
dedication to the music he is (I would argue) one of the great 
composers of our time.

When I first started playing guitar, my teacher barely had me 
playing anything, but we talked a lot about music theory, and 
that made learning easier later on. We need to be careful that 
making things easier for beginners doesn't hurt them in the long 
run.

> For example, there used to be a lot of excitement about what 
> computers could do for education. Those visions have not 
> materialized, and it's not clear that computing is doing 
> anything non-trivial in education for reasoning ability, 
> unlocking math aptitude, writing creativity, etc. It might 
> actually be a net harm, with its effects on attention spans and 
> language development, though this will be very complicated to 
> assess.

I think it is often harmful -- we're teaching people to use the 
tech rather than using the tech to teach people.

My Kiwanis club gives money to our kindergarten teachers every 
year for school supplies, and the teachers generally come and 
talk about what they're doing with the kids. The first year they 
used iPads they weren't that happy -- they should be reading from 
a book, they're too young, etc. The next year they were showing 
off what they could do with the kids now; they still had 
complaints, but they were able to help kids learn in ways they 
could not previously do.

How we use the technology determines whether it's positive or a 
negative. We just need to quit placing tech in schools because 
it's shiny and use when it's beneficial.

> Forcing people to learn Vim or Emacs, grep, and poorly designed 
> command line interfaces that dump a bunch of unformatted text 
> at you are disastrous decisions from a pedagogical standpoint. 
> (See the BlueJ project for an effort to do something about 
> this.) They do nothing to illustrate what new and exciting 
> things you could build with computers, and they seem to mold 
> students into a rigid, conformist nix, git, and markdown 
> monoculture where computing is reduced to bizarre manipulations 
> of ASCII text on a black 1980s DOS-like screen, and constantly 
> fiddling with and repairing one's operating system just to be 
> able to continue to work on this DOS-like screen (Unix/Linux 
> requires a lot of maintenance and troubleshooting overhead, 
> especially for beginners – if they also have to do this while 
> learning programming, then programming itself could be 
> associated with a life of neverending, maddening hassles and 
> frustrations). The debugging experience on Unix/Linux will be 
> painful. From a pedagogical standpoint, this situation looks 
> like a doomsday scenario, the worst CS education approach we 
> could devise.

This reads more like a rant than an analysis of programming 
tools/procedures. You and I seem to have had very different 
introductions to programming.

The idea that we should no longer be stuck with text-based 
odd-looking programming languages and tools is kind of like 
claiming that since we can get running water on the 30th floor of 
a building, plumbers shouldn't have to deal with the mess of a 
septic tank. There must always be somebody at the low-level. The 
projects you mention that are heading the direction you prefer 
are able to do so because somebody else had done a lot of the 
messy work (or they're doing the messy work for their users). 
There will always be a programmer working in the sewers to let 
another work from the penthouse.

After we "fix" programming, are we going to tell the chip 
designers that things should be simple and intuitive enough that 
anyone can build a computer processor?


More information about the Digitalmars-d mailing list