Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Education

Better Tools For Programming Literacy 317

waderoush writes "Adam Wiggins, co-founder of Heroku, agrees with anthropologist Bonnie Nardi that programming isn't just for geeks. The problem, he says, is that today's tools for teaching programming are woefully inadequate. In a commentary, Wiggins argues that there are two major gaps preventing programming tools from being accessible to beginners: 1) they're too fussy, requiring extensive setup, and 2) they're focused on the technology rather than everyday tasks. A good tool for learning programming, Wiggins argues, would emulate an Excel or Google Docs spreadsheet – beginners would be able to fire it up instantly, and would be able to get useful things done right away. (He's dismissive, though, of visual programming tools that 'attempt to hide logic behind a point-and-click interface.') 'Broad programming literacy is crucial in a world increasingly made of computers,' Wiggins says. 'Despite common stereotypes, programming is not out of reach for the average person,' as long as the tools are easy to set up and specialized on the programmer's task."
This discussion has been archived. No new comments can be posted.

Better Tools For Programming Literacy

Comments Filter:
  • by slim ( 1652 ) <john.hartnup@net> on Wednesday January 09, 2013 @07:39AM (#42530333) Homepage

    I'm not sure he knows what he's asking for, but I think I know what might address his concerns, and it's basically more embedded languages in apps that people use.

    Lots of people learned simple procedural programming with Word/Excel macros. Record a macro, look at the code generated, amend it. Now some people do it with VBA, but I'd say that VBA is more hidden than the old macro language was.

    He says people respond "OK, that's cool but what could I use it for?" - and the answer is anything repetitive or mundane that you find yourself doing at a computer. If you find yourself repeatedly going through the same sequence of clicks, a coder thinks "I want to automate this loop". A non-coder just accepts the drudgery.

    The Raspberry Pi version of Minecraft can be automated with Python. Anyone who's laboriously built something brick-by-brick, click-by-click in Minecraft out to be impressed by a few lines of Python doing the same job in the blink of an eye. We need more apps that work like that. We need to get to the point where people demand it.

  • by JaredOfEuropa ( 526365 ) on Wednesday January 09, 2013 @07:45AM (#42530363) Journal
    Don't confuse programming with software engineering. The latter does require a good deal of talent, education and experience. But programming? I agree with the author that many people can learn, given the opportunity and the right tools.

    Case in point: my high school taught a (somewhat unusual) computer class; this was in the mid-80s in what you might call a good high school (the Dutch high school system is divided in levels, the highest being "pre-university education" which was the level of my high school). The class consisted of some basic computer science (what is a computer, CPU, I/O bus, etc) as well as hands on programming in BASIC. This was a mandatory class which meant that we had a mix of geeks and non-geeks sitting in, but pretty much everyone was able to grasp the basic concepts of computing, logic, and programming, to the point were students were able to translate simple problems into working programs. Does this produce useful programmers? No, but it helps getting more people interested in the field, and in my current line of work I can see a clear difference between people who have had such a basic education in computing, and those who haven't. For people in IT who aren't actual software engineers, it's still useful to know a little bit about computers and programming.

    To achieve this, having the right tools is important. Complex tools may be necessary when writing complex software, and a software engineer refusing to master complex tools because they are complex is silly, but for a beginner, complexity distracts them from what they are actually learning: writing a program. That's why BASIC is still a good tool for teaching laymen about computers; it might not be a very elegant language with stuff like GOTO, but beginners can have a working program up and running in minutes, doing simple input and output. Contrast that with something like C, which requires you to set up and master a compiler first, which is no easy task for someone just starting to program.

    Your example of writing is a good one. Like programming, this too is something worthwhile to teach to the masses, and many are able to gain a basic proficiency in it. But you woudln't give a calligraphy pen (or a complex programming tool) to an amateur, you give them a BIC pen (or something like BASIC) so they can master the basics of the art without having to learn advanced tools as well.
  • Programming (Score:5, Interesting)

    by ledow ( 319597 ) on Wednesday January 09, 2013 @07:56AM (#42530417) Homepage

    I have to agree. I've always said that 50% of modern programming is having the right tools, and the right tools configured correctly.

    Introduce someone to C. Now explain that even though C is standardised, there's no "standard" way to compile a C program, to port a Makefile, to have a program compile the same everywhere without manual work ensuring so, or even to start debugging. And then show then a Visual C++ project file and tell them they have to manage it and make sure it works even if their primary platform isn't Visual C++.

    It can get horrendous. Sure, most Linux installs come with gcc set up and you can compile a basic C file and get a basic executable (called a.out with NO OUTPUT to tell you that, for stupid historical reasons, which still blows my mind), but anything beyond that and you're learning the tools more than the language.

    I personally have a deep-set hatred of Makefiles. I honestly can't stand them as a programmer and avoid them like the plague. I get the C preprocessor inside-out and can fancy macro tricks that amaze even me, but I can't be bothered with Makefiles and their separate, unrelated, horrendous syntax. But as a user, they are great when I just want to make a simple change and then recompile without fussing about where my compiler path is, etc. All their alternatives? I have the same problem, but at least plain Makefiles work the same everywhere if they are well-written.

    Even IDE's only mask those same details and thus cause more problems. Standard debugging of a problem for a beginner is to google the error messages from the compiler / linker because it really is that atrocious to try to understand what they actually mean.

    I have a large C project on the go at the moment. It's several dozen code and header files and the same again in associated resources, etc. It took me an hour to work out how to stop it uploading the resource files to the SVN repository and even now I can break it when I add a new resource file without meaning to. It's a nightmare that only compiles because the IDE generates a hidden makefile, runs it through MinGW's make tools and then runs MinGW's gcc to get it to compile / link. I gave up about the five-object-file mark of trying to compile it myself but in other projects with other people's code, I've literally deleted the Makefile and wrote a bash script to do the job instead, they were that horrendous to understand.

    Debugging is also a major bugbear. I know how to load a file into gdb, set a breakpoint, execute it and inspect variable values. Manually. And that's it. I don't even know what half the commands on the menus are supposed to be used for or the correct syntax to make them work and it's not like I haven't tried. Debugging is best done through an IDE that does it for you (still using gdb) and even then the tool doesn't get everything right (I often get out-of-sync line numbers when single-stepping through a program in Eclipse).

    I have taught beginners programming since I was a teenager, and it's only got harder. If I was to write a book on, say, C now, I would feel obliged to supply a disk and include a chapter on how to find the compiler setup program, how to install it, etc. so that I could be consistent throughout the book knowing they were using the same tools and the same versions so I could show them how to debug, etc. Just saying "compile this hello world" can be a book in itself, depending on their background, experience, and computer setup.

    I frequent a C programming board and most of the problems I see are people using obsolete tools (e.g. Turbo C presumably because it's "free" and their instructors were trained on it), or no tools at all (i.e. no capability to debug, manually typing in compile-lines, etc.).

    The next most common set of problems is not understanding how to use those tools or interpret their errors ("_main is undefined", etc.). The next set is not understanding how to write something that doesn't give a compile warning/error (usually because they've star

  • by gweihir ( 88907 ) on Wednesday January 09, 2013 @10:44AM (#42531753)

    Jeff Atwood has some very nice observations about this from the real world. Also highly entertaining:

    - http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html [codinghorror.com]
    - http://www.codinghorror.com/blog/2010/02/the-nonprogramming-programmer.html [codinghorror.com]

    One claim is that 199 out of 200 people applying for a coding job cannot code at all. The examples given are hilarious (or deeply depressing) and there is every reason to believe the observations described. Some of the links are also eminently worthwhile.

  • by slim ( 1652 ) <john.hartnup@net> on Wednesday January 09, 2013 @12:08PM (#42532907) Homepage

    This thinking is like saying "a full piano is too difficult, so if we give people a little toy piano they'll be able to learn to play".

    When I was young I had a little Casio keyboard with auto-accompaniment. It allowed me to experiment with chord progressions using major, minor, major 7th and minor 7th chords, before learning to play those chords manually. It's not a bad thing. 30 years later, I'm able to transcribe chord progressions almost without thinking - something a number of my musical friends find astonishing.

    Perhaps I'd have developed that skill without the dumbed down learning tool - but it definitely lowered the barriers to entry.

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Working...