CP4E: Computer Programming for Everybody
A proposed research effort "to improve the state of the art of computer use, not by introducing new hardware, nor even (primarily) through new software, but simply by empowering all users to be computer programmers."
Summary of Where it Succeeds
Summary of Where it Fails
- For political or social reasons, no professional programmers are available
- Time-saving shortcut intended to be used only by the originating user
- Prototyping - has the advantage of a domain expert behind it
- When the user takes 4 times longer to make the same program as a programmer, it's not economical.
- Newbies have no experience with maintenance and techniques for improving maintenance. While some users pick up programming quickly, maintainability usually requires experience. (Maintenance is often more expensive than first roll-out in the long-run.)
- Difficult to hand-off because most users of the tool don't program in it also, and it's not a standard "IT shop" programming language. (If you hire a domain tool expert who also knows its programming language/interface, then you are essentially hiring a programmer, not a domain program user. Thus, they don't qualify as "everybody".)
CP4E with Python
Though the proposal starts with a reference to XeroxParc
, it uses PythonLanguage
, not SmalltalkLanguage
. (Maybe not so odd; the proposal is made by GuidoVanRossum
, the creator of PythonLanguage
.) One could argue for other languages, but PythonLanguage
is not the worst possible choice.
Here is an interesting (but short) interview with GuidoVanRossum
about using Python to teach programming to non-computer science people: http://www.linuxjournal.com/article.php?sid=5028
EditHint: This page contains much that is interesting, but is hopelessly ThreadMessed. Perhaps it's time to start distilling the information from it.
One obvious place to start editing: leave all the Python-specific stuff here, and move all the more general, is-computer-programming-for-everybody? stuff to a new page (IsComputerProgrammingForEverybody?
, perhaps). Or vise versa: PythonForEverybody? and general stuff here.
CP4E with Python
Where does Python need improvement for beginners?
How about a list of PythonProgrammingProjects?
which are graded according to difficulty?
In the end, programming is much more about problem solving than syntax. What newbie programmers need are programming problems which are neither too easy nor too difficult, Projects which will challenge but not overwhelm the new programmer. Ideally, I think, a good programming project (for a beginner) should be solvable within the time-span of a single afternoon-- for relatively instant gratification.
Python doesn't come with a simple GUI builder. A beginner should be able to make a nice dialog box with minimal effort. This is the obvious thing to fix.
PythonCard, a HyperCard-like Python environment, seems like the solution to this. HyperCard was very easy to teach to people familiar with GUIs, but not programming. -- GeorgePaci
And the syntax is tricky. Case sensitivity is a big problem. An editor which forces valid syntax would help.
A big issue is that programming requires clear and logical thinking. This is hard. A GUI which manipulates semantics could help. As in "Do you want me to make sure this array is sorted?"
CP4E in general
I don't think beginning programmers necessarily need to be developing dialog boxes that early in their careers. Event-driven programming is kind of subtle. I'd rather have them learn with procedural console I/O driven programs. Ask the user for some data, process it, then output some data.
On the other hand, I agree that incorporating some sort of GUI into the learning process can help beginners who are intimidated by the debugging process. See KarelTheRobot
. -- SteveHowell
I disagree with the console I/O approach, simply because beginners get bogged down with reading text line-by-line (or record-by-record), parsing it into words/commands/data, checking for invalid input formats, and so on. Many would-be programmers give up at this stage, because it is just too frustrating, and they are left with the impression that all programming is like this. The benefit of a GUI approach is that it generally simplifies the I/O model, allowing beginners to think more about overall program logic. --KrisJohnson
I would just start them with output only. The compute something, and then they output it with output(). If that's too frustrating for them, they don't have much of a future in it, anyway. For input, make sure they have a real simple API like readString, readNumber, and have your API strip off the carriage returns for them automatically. -- SteveHowell
Another drawback of console-based teaching is that, well, students have to use the console. Assuming that most students are accustomed to Windows and other GUI interfaces, using a command-line is one more hurdle they have to jump before they can get to the good stuff. -- KrisJohnson
Well, I guess I should clarify that I like the idea of learning stream I/O before graphical I/O, but I have no objection to starting the students from within an IDE. I actually like the idea of learning the command line before learning to program, though. Giving instructions to the computer one line at a time is just a simple form of programming, after all. A beginner can go a long way with a few commands like ls/dir, cd, and perl/cc/javac/python. Python has a nice, friendly interpreter mode too. Getting hello-world up and running in a command-line environment is a great warmup for more sophisticated detail-oriented tasks. -- SteveHowell
You like the command line because it's rudimentary programming. But why do we have to go back to the ancient technology of the console to be able to program our own machine? Just why is it that the GUI doesn't allow for rudimentary programming? As a simple example, why is it that one can't set up scripts and pipes using a few mouse clicks and gestures? Why is it that every GUI application is fat and bloated so that X-Window programs resemble DOS programs more than Unix? Why is it that the GUI doesn't have a sign language (UML diagrams maybe?) the same way that Unix has "lots of little programs"? Why is it that the GUI doesn't have a viewable history to see what was executed? If you want to teach ComputerProgrammingForEverybody
, then invent the GUI equivalent of the modern programmable shell. The killer app for it might be non-linear pipelines. -- Anonymous
- Many operating systems and applications have a recordable scripting system, which lets you record a series of actions into a script. Examples: Unix command line and the 'script' utility, MacOs and AppleScript, many editors (Emacs, vi), some Microsoft applications and VisualBasicForApplications. The nice thing about this is you are left with a program you can tweak without having to start from scratch; a kind of template based programming.
As much as we humans despise certain poorly designed text interfaces, we still like text. A picture might say a thousand words, but try to translate your paragraph above into a picture, and you'll see the converse is true as well. Anyone who has ever driven himself mad trying to build a Visio document will tell you it's a relief sometimes to just express relationships with text. (See GraphViz
, for example.)
I have seen at least one tool that let you build programs by combining some sort of graphical primitives, but I forget its name. I don't think any one ever built serious programs with it. -- SteveHowell Could you be thinking of SanScript? (See http://www.nwoods.com/sanscript)
There are a few such programming languages: some DataFlow? languages, and tree-rewriting languages such as WouterVanOortmerssen's Aardappel language.
I agree with Anonymous that the console is archaic, and should not be used in the teaching of new programmers. I don't understand why so many people think that a teletype emulator is the best way to interact with a computer. However, I still think programs should be written using textual programming languages until someone can create a useful GraphicalProgrammingLanguage
. -- KrisJohnson
This subject is very flamebait. For example, the console being "ancient", I'm still of the opinion that GUI never contributed anything to usability -- quite on the contrary. The reason the C64 was easy to program was that (1) you didn't have to know about the file system to write programs, (2) you didn't have to learn an editor, (3) you could try out code snippets while coding and (4) it was easy to see the state
of the computer, because there was no multitasking, windowing and such. Ease of programming lies in what you don't
have to learn, and GUI (as I/O in general) is one of those things. -- PanuKalliokoski
See also InTheBeginningWasTheCommandLine
I will defend the console interface, although I don't think it's the best
or only way to talk to the computer. The console interface has a simple metaphor--normal human conversation. I say something, the computer says something. Repeat. Not very complicated. It's great for simple tasks like "compile this program" or "show me what folder you try to run files from." It's not so great for more complicated things, like heavy duty file maintenance, although it can do that from the command line if you're patient. Since programming demands patience anyway, I don't see the fact that the console also demands patience as a drawback.
Finally, the "teletype" aspect of consoles--i.e.
you send commands to a remote processor--still makes sense in certain academic environments where students share computing resources. This makes less sense, though, as PCs get more powerful.
Why are console and GUI an either/or issue? Why can't one program one's GUI, no matter how rudimentarily, as well as program one's console? Perhaps it's the either/or attitude of skilled programmers that prevents them from creating a programmable GUI? Why can't all the advantages of the console not be seamlessly integrated into a GUI? Instead of dealing with a monolithic X terminal, why not have a mouse gesture open a single-line input stream? Why not extend the transparency of X terminals to a single blinking cursor in the GUI that accepts console input? Why not integrate GUI and CLI history so that one can see "<double click>program" at the same level as "program<enter>"?
Why should people be content with GUIs no more sophisticated nor programmable than DOS? Is this an example of the WorseIsBetter
philosophy? Something alone the lines of "If you want a history of mouse double-clicks, why don't you drop to bash?" Perhaps people should learn to stop tolerating the worse and start demanding the better. Only when people stop defending the past will they unleash the creative energies needed to imagine a better future. (BurnTheDiskpacks
There are plenty of programmable GUIs out there. MicrosoftOffice comes to mind. But I think this is moving away from the topic of the page. -- KrisJohnson
Yep, and there are also GUI programs that incorporate CLI features. A lot of editors let you map a keystroke to an OS command, and they redirect the output from the command to a streamed window within the GUI. GUIs and CLIs can obviously coexist and overlap.
Back to the earlier debate--I use GUIs all the time, but I like stream I/O for writing the types of small, interesting programs that are often enriching for newbies. Newbies can write GUI programs quickly given the right environment, but I'm not sure they'd be focusing on the most interesting parts of constructing software. -- SteveHowell
CP4E in general
One of the best things about learning programming with BASIC (20 years ago, now!) was that it was very interactive: if I wanted to try out the "print" command, I didn't need to write a program and run it--I could just type "print $a, $b" at the command interpreter prompt and see what happened.
(which all us little hackers hated because we had to pre-declare our variables) had the same feature: you can try things out, fixing them as you go, then commit them to a program when you're confident you're on the right track. Ditto for ForthLanguage
(which I encountered in the form of GraForth?
is very adamant about the importance of interactivity. And ditto for Lisp, and practically any other language with interpreted roots.
When I work with languages that aren't interactive (in this sense)--e.g.
Pascal, C, Java -- I miss the little command interpreter prompt. The closest thing was usually the debugger, which isn't really the same. Other people obviously missed it, too: someone has written a Java console that lets you type a line or two, then compiles it into a throwaway class and executes it.
When I'm working with web development, I use the unit tests to provide interaction and quick feedback: change a form, run its UnitTest
in echo mode, see how it looks.
So, given that we're going to be programming with text for the foreseeable future, why wouldn't you want a way to feed lines of text--tiny little bits of programs--to your language environment to see what they do? -- GeorgePaci
Very true. PythonLanguage
would be other good examples of interpreted languages that have nice interactive modes for testing out simple concepts. -- SteveHowell
There are two needs here. One is the need for an interactive environment, which makes exploratory programming so much easier; python has this. The other is the need for a graphical interface, which makes learning programming so much more comfortable (in that the interface is something the user is familiar with, rather than that writing it is easy); python does not have this.
-style event handlers. The user could write their program logic in python and their GUI in HTML, then plug them together with onClick attributes etc. This would require a python-friendly browser-like thing to be built into the environment - essentially, a stripped-down version of FireFox
, or just Gecko with some bits added on. Perhaps you could use it like this:
name = window.main.user_name
gui.tell("Hello " + name + "!")
windowHtml = """<html>
<input type=text name=user_name>
<input type=submit onClick="sayHello()">
window = gui.show(windowHtml)
Don't ask me how the namespaces work here - i'm BrainStorming
! Oh, and gui.tell is a convenience method which pops up a dialogue box (or a little ordinary window) with some text in - inspired by HyperCard
This does require that users learn HTML before they learn python, but i don't think this is a huge problem - indeed, it might be good to get them to learn HTML first, as a 'zeroth language', since it's very simple, gives immediate positive feedback (web pages!), and is of quite a lot of practical value.
Learn HTML before learning Python? Learn HTML before
I am not sure what you are proposing and why learning HMTL first is a bad idea just because it may be hard. It is more practical if you ask me. As far as SeparateDomainFromPresentation
, a lot of that mantra is malarky in my opinion. --top
See also: DamianConway
's paper Seven Deadly Sins of Introductory Programming Language Design
(available from his home page)
Summary of the seven major "sins":
- 1. LessIsMore: paradigm purity can get in the way of practical problem solving...
- 2. More is more: ...but you can also have too much semantics to learn
- 3. Grammatical traps:
- Syntactic synonym - multiple ways to do the same thing (i.e. array[i] == *(array+i) in C)
- Syntactic homonym - same syntax has different semantics in different contexts ("static" keyword in C)
- elision - allowed omission of a syntactic component (Lisp superbrackets)
- 4. Hardware dependence: i.e. different length of "int" in C
- 5. Backwards compatibility: language elements included for familiarity with prior languages have no benefit for a first-time student (i.e. Java's and C++'s C-like syntax and Scheme's retention of assembly mnemonics "car" and "cdr")
- 6. Excessive cleverness: obvious to an expert but not to a novice (i.e. C/C++ declaration syntax)
- 7. Violation of expectations: such as syntax traps ( "if (c=1) ..." in C ), strange precedence rules, and integer overflow
and seven recommended introductory language design principles:
- Start where the novice is
- Differentiate semantics with syntax
- Make the syntax readable and consistent
- Provide a small and orthogonal set of features
- Be especially careful with I/O
- Provide better error diagnosis
- Choose a suitable level of abstraction
One of the authors, DamianConway
, also wrote a nice book about object-oriented Perl, if you're into that kind of thing.
(expanded by IanOsgood
I think these "sins" are questionable. For example, I've never seen someone learning programming to be bothered by sin #4. -- PanuKalliokoski
certainly qualifies as ComputerProgrammingForEverybody
(who has something they need the computer to do) And experts in their own fields certainly know what that is more than the expert computer programmer who doesn't know the field. It is part of the reason that productivity has been increasing for many years. It was the non-programming specialist who saw in microcomputers a way of accomplishing automatically what had to be done manually because of the Main Frame mindset that said that their computing concerns were not economically feasible or important enough. The computer for everyone has been the result.
The real challenge is not the language, it is sharing programs safely. Such is the design goal of WikiTalk
. The design is still in its infancy, please participate. WikiTalk
is language neutral in that Python, SQL, shell, Java, SOAP etc. code can be used at the will of the writer rather than forcing a particular language. At the same time it is becoming a language on its own based on natural language, semistructured text, RELAX NG, and XSLT. The boundaries between program and code are obliterated. -- JimScarver
CP4E: fundamental problems
I have a problem with this idea--it smacks of both a denigration of software development as a profession and seems to imply that everyone should be able to tell a machine what they want it to do. Look at the tax system--everyone with an engineering degree can do the math necessary to calculate their taxes, but many choose to have someone else do their taxes. Why? Because some things are better left to the specialists. A similar trend exists in auto maintenance--why should I buy and store a set of tools to change my engine oil, filters, brakes, etc, when for less that half the cost in materials, and much less in my time, I can drive the car to the shop, wait 30 minutes, and have it done for me? Software development is not
trivial, and the average person without training in the field will produce poor solutions. -- PeteHardie
CP4E with Python
Inspired by CP4E, Yorktown High School is now in its 4th year using Python in an intro CS course. My goal is to get as many students from as broad a range of interests and backgrounds as possible into the course. I do not aspire to make computer programmers out of everyone. I do want to empower all my students with a greater understanding of what a computing machine is and what it is capable of doing. I want to "demystify" computer programming for all students in the class. Given how important these machines are becoming in the production of our world, such an understanding has important implications for democracy. It has been both fun and challenging working successfully with a very heterogeneous population of students. Using Python has played a big part in making the course as successful as it has been. Most students in the course are very successful, yet having very varied levels of understanding has in no way held back the most advanced students from becoming computer programmers. -- JeffElkner
CP4E: fundamental problems
You can hire a CPA to do your taxes, but is it really worth it if you're using the short form and can get it done in a half hour? In the same way, I've found many uses for just firing up Python and typing a few lines to get a job done, or writing a little one-like Perl or Awk program to do a job for me. Who's to say that others wouldn't benefit? And even if the average person doesn't need to program, learning how to do so might make the computer itself seem like a less mysterious and cryptic device. -- NickBensema
So maybe it's ComputerUseForEverybody?
, instead. Programming is more than 30 minutes of toss-together. Sure, lots of small companies have their personnel database handled in FoxPro
by the receptionist, but when the CEO says "Develop our enterprise-wide production DB system, and by the way, you can use this database code that my secretary has written to get started", you've got an entirely different kettle of fish. Would you call using the short form for your taxes TaxAccountingF
orEverybody? -- PeteHardie
. Almost every one else writes on an amateur basis, but can we say the same thing about programming? There seems to be discontinuity in the spectrum with programming. -- SteveHowell
I think that the valuable thing about there being programming tools for everybody is simply to maintain a pool of quality programmers for the future. Part of the reason that I attribute my ability to grasp computing concepts is that I have been programming, on a limited basis, since I was 5 or 6.
Who buys their kid a full copy of VC++? It's way too much. I think that Python is ideal for this sort of thing because it's already free and it seems to be quite simple. -- KenWronkiewicz
My parents did--not VC++; it didn't exist then; but an equivalent product--for which I am eternally grateful to them. -- DanielKnapp
Yes, but ideally, this should exist without parental interaction. I'm glad that my parents purchased me plenty of different software packages over the years, but, at the same time, my parents appreciated what could happen if I learned computing. But both minimal parental appreciation of the potential of learning to code and lack of finances can make it hard for a parent to purchase VC++ for their kid. -- KenWronkiewicz
I think that programming -- at least at the basic level -- is an important thing to learn for any budding computer user.
Simple shell or batch scripts make it a lot easier to do repetitive and/or time consuming tasks. I think that learning a couple languages (even just at a superficial level) would give a user a better understanding of how their comnputer works, and also it would cut the fear most people have about using electronics and computers. I am somewhat pessimistic about the average person's ability to understand computer logic. I have memories of many people in math classes having problems understanding how to solve "word problems" because they weren't able to quantify what was being asked. Most often, the problems one encounters in writing programs are more complex than simply plugging numbers into a formula. Maybe I am wrong, but I'd like to hear other's opinions on this issue. -- TimothySeguine
CP4E in general
A mere understanding of what's involved in programming is helpful for the computer users of the future. They will be able to understand that you can't write a big complex program in a day or a week. -- KenWronkiewicz
Case Study: Lotus 1-2-3
Re: "Keep in mind that programming is a basic skill that will soon be required of everyone"
[Unlikely, most internet users can barely figure out how to use email and browse the web, programming isn't in their future. When they learn to not open up executables from people they don't know, and figure out that america online isn't the internet, then maybe... maybe... nah... it'll never happen.]
Butlers are too expensive even if immigrants are cheap. Similarly, having a programmer at your beck and call is simply too expensive. The same logic eliminated typists as a profession.
But I find self-programming as likely as self-auto-repair.
The closest thing I ever saw to programming-for-the-masses was when Lotus-123
allowed one to save keystrokes into "macros". It was an incremental way to learn because it built on something users already knew: the keystroke commands. The Lotus menus were closely tied to keyboard sequences. There was even a "recorder" tool to save keystrokes. Just throw in IFs and LOOPs and it was then TuringComplete
. Boatloads of accountants became programmers. I've seen some fairly sophisticated stuff. It ended when MS-Excel was forced down their throat after Lotus fell from corporate grace. MS-Excel programming is about as easy-to-learn and intuitive as an Apollo lander. Plus mousing reduced the reliance on keyboard-based commands. The lesson for CP4E is to:
- Build on something a user already knows rather than throw them in the deep-end of the pool.
- Base it on a domain-specific tool set.
- Text commands (such as menu letters) are perhaps easier to convert into programs than mousing (MouseScriptDisconnect).
However, in general, newbie code is hard to maintain because the newbie is so focused on just getting stuff to run that maintainability and abstraction are something they are not yet ready for. And guess who they call after they've made a BigBallOfMud
? Making maintainable, readable code is a skill difficult to pick up quickly. But the keyboard macro style was great for minor personal automation.
Some software engineers regard VisualBasic
to be programming-for-the-masses, as these languages allow you with little experience quickly to write unmaintainable code.
Hmmmm. Does easy-to-learn equal "bad"? Note that LispWeenie?s consider Java in that category also.
Yes, I've noticed most people think easy-to-learn-or-user is "bad" / "lame". Try looking at all the linux "gurus" that look down on the other linux users because they don't use the command line as much.
This page is ripe full of LanguagePissingMatches and HolyWar fodder.
I caught myself doing the same thing yesterday -- sneering at someone who declared some variable as "long", when obviously
declaring it as char
would be ever so much more "efficient".
When will I stop worshipping the false god of PrematureOptimization
CP4E in general
Not everybody wants to be a programmer. Users would benefit from being programmers (but do not know it). Users are also the easiest to teach, since the program they want to change is the one they use. As we all know, users are expert testers - they must be to find bugs that the programming discipline has missed. Training users to modify their own programs has many benefits and few drawbacks. The obvious drawback is that sometimes they break the system. So you need to provide a test and release environment with the released application.
If this is done, users will evolve their own systems. Not all of them. Just some of them. Not all of them will improve it in all senses, but they all satisfy their needs.
There seems to be a spectrum of ideas here:
- Everyone should be required to learn to program maintainable, readable code, and write their own text editor from scratch.
- It would be a Good Thing if someone were to develop a programming environment that made it so easy to program, that vast masses of people could use it that are currently too intimidated by current tools to even try.
- Sometimes a user has an idea for a tiny little program that he will use once or twice, saving him an hour of doing something manually. Multiply this by thousands of users, and it's better to let the users do the simple things on their own (such as putting the gas in the car), and save scarce professional programming time for the complex tasks (adjusting the engine timing).
- It would be a Good Thing if people understood how complex programming really is. Rather than struggling for months to build a rickety, insecure BallOfMud?, perhaps it would be better all around to hand it off to a specialist who could bolt together a high-quality piece of machinery in a few days for a pittance.
- Only professionally certified programmers should be allowed to touch compilers and similar highly dangerous tools, which shall be kept under lock and key from 5pm until 8am the next day.
The ends of the spectrum are straw men (I think).
See Also: CompilingVersusMetaDataAid