Slashdot Mirror
Better Tools For Programming Literacy
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."
People can't program the VCR clock. (For the young ones: Back in the old days we called the Tivo "VCR". Just like everything must have a camera today, back then everything had to had a clock, and it had to be set manually.) You can barely teach (most) people algorithms that aren't completely linear. If you think you can teach them to develop algorithms, you need to get back in the trenches and deal with normal people. Developing programs means to understand problems in depth and to correctly answer a lot of "what-if" questions about complex systems. Normal people actively try to avoid doing that kind of thinking.
It is a far more demanding task that "geek" would qualify you. It requires talent, education and experience. Those that gripe about the tools do not get it or have never gotten beyond toy examples. Sure, a better tool helps. But when you create software (as opposed to slapping together some disaster waiting happen), the direct level of skill needed to use the tools is actually a minor concern. In fact, the language used is a minor concern, the problem is what matters. Insofar I even agree with the article. But refusing tools that are a bit complicated is the hallmark of somebody that does not get it.
Case in point: Pen and paper are exceedingly difficult to use for writing. Yet we spend years on every person to qualify them to use it. Yet compare the complexity of pen&paper on one side, and a computer on the other side. Anybody expecting the computer to be easier to use just has no clue at all.
All that "simple" to use tools for software creation do is cause even more really bad programs to be written, as suddenly everybody and their grandmother thinks they can do it. Like giving calligraphy pens to amateurs. Sure, they can produce some smears, but they cannot produce anything worthwhile.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I just started experimenting Pure Data, and it is an example of an environment that does this quite well. Although it can be very complex when you dig down into it, it's very easy to get started with and create useful objects without the "fuss" that TFA talks about.
A house divided against itself cannot stand.
It seems to me that a great deal of people have this idea in their heads that any and everyone is able to do any and everything. This is bollocks.
Furthermore, blaming the inability to get interested in something or to cross a certain difficulty barrier on the tools is just laughable.
If one can't take the first step in programming and get acquainted to the tools, he won't be able to make the later steps either. It takes commitment and interest. Reducing the first barrier won't bring a lot better programmers, it will bring in a lot more bad programmers that get stuck half way through and don't really help anyone.
He's saying programming is not as simple as Excel because programming doesn't have an equivalent of the SUM() function that does almost all the work for you when you are new to it.
Yet, excel never tells you that you have to use the SUM function, or that A:A means the whole A column, or that $1$3 means it shouldn't change the row/column when spreading the formulas. But he wants the development environment to somhow not require knowledge of how a loop works, or what an array is?
The problem isn't that programming is harder than Excel, at least not if you use a full-featured IDE with a decent language, like Visual Studio with C# 4.0. You can learn to drag a few controls to a new window, double-click on a button, and write something like "MesageBox.Show(textBox1.Text);" in seconds. No knowledge of arrays or functions necessary.
Programming is NOT harder than excel, and there ARE tools that make it as easy as possible. Anything else requires "visual programming" which he states he doesn't want, either. But of course, excel doesn't "hide the logic" from you, right?
The fact is, you need some basic knowledge to do any job. Excel requires knowing the syntax and function names, so does general-purpose programming, just like you need to know the parts of a car, and their use, if you ever want to build one from scratch.
Like an old boss of mine used to say, "They want a fucking big red arrow that points to the answer"
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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.
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
Considering that a basic devkit like Eclipse (sufficient to write a lot of Java code) can be set up by downloading, unzipping and double clicking on the file with the colorful picture, I can only concur.
You are missing a few steps, like installing the JDK and possibly installing the JRE, figuring out what the heck this workspace thing is. The Hello, World example you copied from the Internet also doesn't work because the package doesn't match. Congratulations, Hello, World compiles in Eclipse, but you want to see it as a standalone program. You click on your .java or .class file, 'Windows can't open this file'. After googling the problem, you find out that you need to run it from the command prompt by typing "java hello.class" so you become comfortable with cd.. until you get to your workspace and find the 'bin' folder. You try it, 'java can not be found or recognized'. Now you have to add the jdk to the path.
Other requirements from what I gather are a one-click install and a Microsoft Bob equivalent to ask what you want to achieve.
Maybe they could reintroduce Clippy... "I see you're writing a kernel!"
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
- http://www.codinghorror.com/blog/2010/02/the-nonprogramming-programmer.html
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.