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.
Turn spreadsheets into mobile apps
Not exactly a practical environment for most programming needs. Beside which, you should never trust anyone who scales their website images. Ew!
systemd is Roko's Basilisk.
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.
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Worked for me :D
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
I taught myself programming. Nerds will be.
The rest just enjoy yourselves with twitter.
This has been tried so many times before. The simple fact is that most people can't program.
Simpler tools, or better tools, can ease the incidental burden of having to work with a program.
What they can't ease is the cognitive load of having to remember patterns, and abstract objects, and nested function calls. Most people can't deal with this.
Mr Wiggins has probably forgotten, as I have, the difficulties one faced and overcame when one first learned to program, and so he's forgiven for thinking that if we just made the environment simpler anyone could do it.
I'd argue that python at the shell is pretty simple, but most people can't or aren't motivated to do even that.
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".
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!"
What about our deadline?
You've hit on why most programmers suck. They think programming is about syntax and logic. Kinda like a carpenter who thinks his job is about hammers and saws.
Problem is most are a PITA to set up for the more interesting things. Compiler for a boring PC? easy. but writing code for embedded processors like a Microchip or TI MSP430 are 90X more fun and satisfying than writing yet another twitter client. Setting up those compiling environments are a royal huge PITA. In fact last night I blew 4 hours getting it all set up for the MSP430 on ubuntu, the only distro that has most of what I needed in a repo so I can just apt-get it all. and learned that Ubuntu 12.10 is a steaming pile of advertising riddled crap. so now I need to start again and try debian or slackware and do most of it by hand.
The tools needed all rely on thousands of obscure libraries that are poorly documented as to what is needed. Hell to just compile the openchronos-ng example project for the TI Chronos dev platform I had to hun down 2 obscure Python libs to install.
Why cant this stuff be rolled up in a statically linked blob that makes it easy for the casual guy to download and run?
Do not look at laser with remaining good eye.
Putting programming within the reach of every-day people is to harm [further] things in two ways:
1. Adds to the complexity of knowledge of users and thus creates additional potential for things not working.
2. Reduces further the power and flexibility of most programming which results from the need to reduce the risks of #1.
The kind of high-level programming we are doing today is more "black box" dependant than ever before. When I learned to code, it was BASIC first but then quickly into assembly language for some popular motorola processors. In that realm, I learned to write pretty much everything about how to get input to how to send output. Admittedly there were stll black boxes, but the black boxes were essentially "interacting with the OS" which is one black box we need.
But when the very language we write in is a black box I begin to worry more and more about the mentality of programmers who don't understand the underlying details of what really goes on. I recall someone saying "why do checks this way? use REGEX!" I was like "uhm... what do you think regex routines are doing???" Once again, black box dependency obscures people's understanding of what computers are actually doing.
I'll get off my soap box now, but I will close with this: The problems with today's software is programmers who don't understand computers. This division of "hardware guys and software guys" is ridiculous... every bit as ridiculous as the idea of separating the head from the body (mental and physical) in the practice of medicine.
`Hello World` in Java is one line, excluding stuff that the IDE does for me. While I do hate it when IDEs generate screeds of boilerplate code, I think Java keeps it to a minimum, and I like what Java makes explicit. I wouldn't say it was an ideal beginner's language though.
Hello World is one line in Groovy, Python, Ruby, Perl. Ruby and Python are languages I might recommend to an absolute beginner.
There are three possible approaches in that scenario:
You can't have an in-house team that tries to reinvent the wheel and write software where it's unnecessary, that's pure waste, but for a large organization having a small team that can take care of things that really do need to be done in-house can give a big competitive advantage.
// MD_Update(&m,buf,j);
You're thinking about too large a scale of program. If it's big enough to ask a team (or even a lone programmer) to do, it probably does need a 'real' programmer.
Think more along the lines of typing. In the 1970s, companies had a typing pool. Nowadays almost everybody does their own typing.
I think lots of people would benefit from the ability to write simple scripts -- the kind many /.ers would consider throwaway.
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.
I know, that sounds like a contradiction in terms, but one of my college profs made a good case for the concept.
The value of learning programming for non-programmers is not "I have to get that *@$% computer to do what I want". It's "I have to learn how to break down a large problem into simpler smaller problems, until I know how to solve it." and "I have to recognize the adjustments and adaptations that humans naturally make when solving problems." And as a side effect, it also teaches the important lesson that some problems cannot be solved by convincing people around you to believe in nonsense.
I am officially gone from
Minecraft can be the new Logo/Turtle.
http://en.wikipedia.org/wiki/Logo_(programming_language)#Turtle_and_graphics
It pays to be obvious, especially if you have a reputation for being subtle.
Seems you've never met Lisp have you?
Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
Programming at a professional competancy might be out of reach. But programming badly isn't that hard. As in:
10 print "my sister is ugly" : goto 10
Back in the days of the TRS-80, Commodore Pet, Apple II and BBC personal computers (et.al.), millions of kids could turn on their personal computer and start typing in Basic right away, usually using stuff copied off of a magazine article... at first. But then they could modify their programs and crash them in a million different ways. That caused learning, and very likely ending up producing a generation of people with much higher basic computer literacy than in the general population than today (not including professional techies).
Don't confuse a professional level of understanding with computer literacy. No one confuses the kid who could (back in the day) (mis)use their chemistry sets to blow things up in their backyard and singe their eyebrows off, with National Medal of Technology prize winners. (Or could you?).