Index of Hello World! programs and beyond

Table of contents:
 

Indexes of standalone static text 'Hello World!' programs

The classic 'Hello World!' program is a useful absolutely minimal excercise in how to use a particular programming language on a particular system, but it's useless to show anybody because it's not accessible from the Web. I'm more interested in the analagous program that produces Web-accessible output. See the next section for that. But some people are fascinated with the classic standalone non-accessible program, and have tried to collect examples in as many languages as they can. Here I simply list some of these collections: If you want to see, just for curiosity, the basic syntax of such a large number of programming languages, that's where to look. But for some of the languages which are actively in use today and suitable for use as serverside applications, specifically those languages available on FreeBSD Unix here, my site (starting with the next section) has some advantages: Note: I suppose the perl-only CGI sites such as Tripod, which violate normal CGI by not requiring the first line of the script which identifies the application as either a native-code program or a script for emulation by some other program (showing the directory path and filename for it, such as /bin/sh), and where only pure Perl is allowed, no `shellcommand` calls allowed, are a slight deviation from my uniform standard. But if you stick to pure Perl code, the same application runs equally well in both regular CGI and Tripod/PerlOnly environments, and the CGI protocol itself is identical for both the perl-only sites and the regular CGI sites. And for many people who don't have Unix shell accounts and can't keep their personal computer on the net 24/7 to enable proper hosting of Web pages, free (modulo banner ads) Web-hosting services such as Tripod are the only way to set up either regular Web pages or CGI scripts for others to use, so I consider such sites important to include, so indeed I've included Tripod/PerlOnly here.

Note: The static plain-text and HTML files that start this section are perhaps a major violation in that they don't actually run any server-side software other than the system HTTP server. But they are accessible to *all* Web browsers on the InterNet, even those not equipped with a javascript interpretor or a JVM (Java Virtual Machine) for running applets, so I've included them here insofar as they can emulate actual serverside programs in simple cases. Actually the primary reason I included them here was as a result of a joke (or maybe attempted hoax) where Michael Mendelsohn was posting that HTML should be regarded as a "real programming language" because it can do 'Hello World' just like C can, or that C is no better than HTML because it can't do 'Hello World' any better than HTML can, and I had to point out that the logic was backwards: All HTML WebPages can be emulated by C programs, but only the most trivial of C programs can be emulated by HTML WebPages, so C (and the other languages I cover here from PHP onward) are all more powerful than HTML, so much so that they qualify as true programming languages whereas HTML doesn't. He must have missed my point because I had to correct him once again later. Finally I realized the best way to distinguish true programming languages from "programmed text" engines such as HTML, and posted that, which to this day (2005.Jul.11) hasn't been rebutted.

Note: I know how to write JSP (Java Server Pages), which are very much like PHP except the syntax of scriptlets is Java in JSP compared to Perl in PHP, but I don't yet include any JSP in these examples because I don't yet have access to any J2EE machine with network connectivity.

Note: My "level playing field" (server-side programs only) precludes any client-side scripts such as applets or embedded javascript. Downloadable client-side software, plug-ins for your Web browser, are a completely different topic.

Index of ways to put just static text 'Hello World!' on the Web

Like the classic 'Hello World' program, the programs I'm displaying in this section produce constant output, neither varying with time of day nor being in any way responsive to the user, except for running when commanded to run. But there's one key difference between these programs I'm displaying, and the classic standalone 'Hello World' programs included in other people's indexes I've shown you in the previous section, namely that here I'm interested in putting content on the Web, whereby even putting up a simple text file isn't completely trivial. So first I show how to put a simple text or HTML file on the Web:
txt t/h html
then show you a display language that includes small scriptlets within a basically-HTML WebPage file:
php
and finally here I'll work my way through various ways of setting up regular computer scripts or programs for generating similar Web content:
sh* perl python lisp awk f77 c c++ FlamingThunder java

Static Web pages on public_html:


Simple ASCII text file
(When you click that link, you see exactly what's in the file.)
 
Absolutely minimal HTML file
(This file has exactly the same contents as the ASCII text file, not even one HTML tag added, but because the extension is html it gets processed as a HTML file and is displayed slightly differently.)
 
Click here to see sources (as if you haven't already seen them) and directory entries (this is what you need to see) for above two files.
 
Properly coded HTML file
(This file now has a proper DOCTYPE declaration and charset declaration, as well as html head body etc. tags., and a title, and anything else needed to make it pass inspection as "HTML 4.01 transitional" according to the W3C Markup Validation Service. Also the "Hello World!" text is centered.)
Click here to see the source, and directory entry, of that file.
Note that from here on, whenever my demo generates HTML output, I'll try to make it generate proper "HTML 4.01 transitional" likewise. But in most cases where the emphasis is on programmability rather than format, I'll generate a plain ASCII text file as output instead.
Update: I have more recently learned that HTML 4.01 transitional is not officially supported, and was never intended to be used except as a short-term emergency measure, so I've switched to using "-//W3C//DTD HTML 3.2 Final//EN" instead for my regular Web pages and PHP scripts, and might someday convert these examples to that version as time permits.
 

Mostly-static Web pages with inline script generating dynamic content:

PHP -- Thanks to this tutorial I was able to code a php script, but it didn't work until I got some help and some more help from Ken Robinson. So here it is finally, my first working php script, and here's a listing of the files needed to make it work.

JSP -- I have written Java Server Pages on my laptop, and I've run them on the system at De Anza College, but my laptop has no InterNet service whatsoever, and the system at De Anza College doesn't support external access, so I can't show those JSPs to you. Unfortunately this FreeBSD Unix system doesn't support JSPs at all, so I can't even post a Hello World JSP here to show you. If somebody knows of a free JSP-hosting service, or if you are willing to host JSP demos on your system, please let me know.

Dynamic Web pages generated by CGI scripts on cgi-bin:

Inline interpreted scripts:

Shell script sh to generate fully valid HTML transitional Web page, and other shell scripts csh / tcsh / ksh / bash to generate absolutely-minimal plain-text WebPage
Click here to see the sources, and directory entries, of all those files. If anyone knows of any other shells that are commonly available on FreeBSD Unix, please let me know so that I can include them here too.
 
Perl script to generate the simplest plain-text file via CGI
more advanced Perl script to generate valid HTML transitional
(Perl is the most common programming language for writing CGI scripts.)
Click here to see the source, and directory entry, of that file.
 
Python script
Click here to see the source, and directory entry, of that file.
 

Shell command invokes interpreted program:

CL (Common Lisp) program to generate minimal plain-text page
Slightly larger CL (Common Lisp) program to generate valid HTML transitional WebPage
Click here to see; awk program
Click here to see;
 

Separate program needs to be compiled, but runs directly from CGI:

Fortran-77 program
Click here to see:

C program
Click here to see:

C++ program
Click here to see:

Flaming Thunder program (no longer works, no time to investigate)
Click here to see:
 

Separate program needs to be compiled, then shell script invokes it:

Java program to generate minimal plain-text Web page
Slightly longer Java program to generate valid HTML transitional
(Note: The JVM (Java Virtual Machine) takes a long time to start up if it hasn't been run recently.)
Click here to see:
 
 
 

Index of programs one step beyond 'Hello World!'

The basic idea here is to generate some simple output that depends on current circumstances, such as date and time, or IP number of client/browser. It doesn't in any way need to be responsive to any input from the user. To qualify for inclusion in this "one step beyond" section, all a program or script needs to demonstrate is something that static Web pages (text and HTML files) can't do.
Mostly-static Web pages with inline scriptlets -- php
Directly-interpreted script -- sh* perl python
Shell-script invokes interpreted program -- lisp
Program must be compiled, but then runs directly -- c c++ Flaming Thunder
Program must be compiled, then shell-script invokes it -- java
Request for other people to volunteer examples in other languages
 
*** Why can't I put a h3 here??

Mostly-static Web pages with inline scripts generating dynamic content:

WebPage with embedded PHP shows: Click here to see the HTML+PHP source and directory listing for it.

jsp -- I'd like to get jsp scripts running here, but that requires J2EE which is not available here on this Unix shell host, and it's not the kind of software that normal users are supposed to be installing on their ISP. Maybe somebody has an under-utilized server somewhere with J2EE installed and I could get a free account there just for putting up such software I've developed on my RedHat Linux laptop?

Inline interpreted scripts:

Shell script shows: Click here to see the shell-script and directory listing for it. (I haven't included scripts for any of the other shells available here, on the assumption they'd all be the same except for the #! line at the start. But if you know any other coding differences needed to make this script work when using any of the other shells listed earlier, please let me know so that I can treat them individually here.)

(Nitpick: For the date&time above, it's really the 'date' program that is doing most of the work. The shell is merely passing output from the 'date' program further out to the Web client. But at least with the IP number and PATH, the shell interpretor is doing the work, so this overall is a fair proof that sh can produce non-constant output.)
 
Perl script shows:

Click here to see the Perl script and directory listing for it.
Unfortunately this script uses backtick `...` (known as back-apostrophe elsewhere) to make a Unix call, so this script doesn't work on Tripod.
 
Pure-Perl script (no `Unix` calls)/ (same on Tripod)

This gets the current time since epoch, decodes it into sec/min/hr/dt/mo/yr etc., then tries crudely to format it semi-meaningfully. I haven't bothered to make the output pretty because this is solely to demonstrate that Perl is a real programming language that can produce dynamic content, not to demonstrate pretty formatting capabilities. Notice also that the exact same script on Tripod intercepts the IP number with an internal firewall number, and doesn't provide any PATH whatsoever. If you intend to write CGI scripts using perl, and use free hosting services, beware of these limitations.
Click here to see the Perl script and directory listing for it.

Here's a completely different style of perl script, basically writing a multi-line verbatim copy of the text to be generated, with variable string substitutions from time to time. It's somewhat like JSPs with scriptlets or XML tags, but not as flexible. (But of course you have the full power of perl outside these multi-line almost-literal-strings.) One aspect, however, where it's *more* flexibie than JSP: You can generate not just text/html output, but also text/plain as here.
Click here to see the Perl script and directory listing for it.
 
Python script shows:Click here to see the Python script and directory listing for it.
 

Shell command invokes interpreted program:

CL (Common Lisp) program which produces the same three outputs as the first Perl script (date&time, IP number, PATH variable) but it's "pure", doesn't invoke any shell commands. (Also, because I'm expert at Lisp programming, it was trivial for me to make this program produce a nicely-formatted date&time, exactly the way I like it best.)
Click here to see:
 
Awk has no direct access to time-of-day or any other input of information, except via the one file it has on standard input (or alternately input file named on command line). Accordingly Awk can't perform any one-step-beyond task. But see later where it *can* perform a two-steps-beyond task.

Separate program needs to be compiled, but runs directly from CGI:

C program which produces the same three outputs as the lisp program (date&time, IP number, PATH variable), except not my favorite date&time format, just the default one provided by the standard time library.
Click here to see:

C++ program which produces the same three outputs as the C program (date&time, IP number, PATH variable), exactly, because it is exactly the same code, even the same libraries are used, except it's the C++ version of C libraries here (<ctime> instead of <time.h> for example). The only slightly nontrivial difference is the use of cout instead of printf.
Click here to see:

Flaming Thuder program which produces two of the above outputs (date&time, IP number). (no longer works, no time to investigate; when run from shell, gives error: Segmentation fault (core dumped))
Click here to see:
 

Shell command invokes compiled program:

Java program which produces the same three outputs as the lisp program (date&time, IP number, PATH variable) but it has to cheat and get the environment variables via a shell script, because the people at Sun MicroSystems have decided that because Macintosh doesn't support environment variables, Java shouldn't either, so they have not just deprecated System.getenv(), but made it an illegal method call that prevents compilation of the program. But thanks to a tutorial by Pat L. Durante, which pointed out this absurdity and showed a way to script around it, it's once again easy to use Java to write CGI applications.
Click here to see: After I wrote the above, I browsed further down my Google responses, and found another tutorial which provides a more flexible way for java to read the environment variables, namely by running a shell script as a sub-process, collecting the output from it, then parsing it to build an associative array ("TreeMap" or "HashMap" most likely). Maybe I'll try it someday.

many other languages -- Remember that WebSite with appx. 200 different standalone "Hello World!" programs posted on it, which I mentionned at end of the standalone-hello-world section, before my CGI-hello-world? I'm not interested in duplicating that kind of exercise for CGI-hello-world, but I am interested in collecting additional examples of programming languages that go at least one step beyond CGI-hello-world. Accordingly:

If anybody (other than myself) has done the same sort of thing for one or more steps beyond Hello World, i.e. made an archive of source code for such programs in a variety of different programming languages, including several programming languages I've overlooked here, I'd be very glad to link to their archive from here, just a comprehensive link as I did for the 200-hello-world etc. collections. That would relieve me of the burden of individually including such programming languages myself. If that other archive also allows programs to be run by anyone via the Web, as my programs do, that would be an added bonus. Please let me know of any such archive (with or without ability to run live) you may know of.

Also, if somebody has even one live demo of one or more steps beyond Hello World, including exhibit of the source code, for any language I've not already included here, I'd be willing to make a special entry for it individually. Please let me know if you have found any such.

Finally, if there are any programming languages (must be capable of running in CGI environment and going one or more steps past 'Hello World') which are available here on FreeBSD Unix, which I haven't yet included here, I might be willing to find a tutorial for such language and teach myself enough to be able to demonstrate it here, both the basic CGI-hello-world program and the one-step-beyond program, just as I already did for Python. Does anybody know of any tool to scan the disk here on FreeBSD Unix shell machine and report any files which are in fact compilers or environments for programming languages I don't already know about?

If you have any information of existing Web sites like I am seeking, or if you would volunteer to set up separate demos of various steps past "Hello World!" on your own WebSite using your favorite programming language I haven't yet included myself, as I've requested above, please make suggestions or volunteer.  
 
 

Index of programs two steps beyond 'Hello World!'

The basic idea is to take the encoded-form-contents as raw input (don't bother to decode it correctly, just take it as one big mess that you know contains embedded strings of interest, and you don't have to accept both GET and POST methods, just do whichever is easiest in any given language, or pick one at random so you don't have to do both already here) and check for certain strings in it as commands to perform simple tasks. As a result, the user can vary the form contents somehow to thereby control, possibly in some crude and hackish way, what tasks get performed by the server and what tasks don't get done. (Remember: This is just a minimal proof of capability here, to prove a particular computer langauge is in any way capable of responding to user data input to effect control of the server application. Doing it the "right" way comes in the later three-steps-beyond section.)
html / php sh* perl lisp awk c c++ Flaming Thunder java
 

Programmed text, i.e. pages of text with links user can browse:

(These are really cheating, but they're cute, so I'm including them here.)
HTML: Rearrange 5 numbers / VoiceMail / Checkboxes: DATE/IP/NAME (See how I made that work)

 
In a programmed text, as above, all the options must be set up beforehand, as links from one page to another. The only option the user has is to click on one change-page link or another. Such does not qualify as truly responsive to user's input in the same way that the following do. Below, the user can actually fill in a form with arbitrary text input, or check boxes or buttons, etc., and then submit the form, whereby the server processes whatever the user entered. (The user can also manually change the query string when using the GET method to obtain options not available from the form as given.)
 

Mostly-static Web pages with inline scripts generating dynamic content:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time (messy format)
See your browser's IP number
See programmer's name
instead of text-fill-in field, for running the same .
See source.

Inline interpreted scripts:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See programmer's name
instead of text-fill-in field, for running the same .
See source.
Note: The above script makes a call to grep followed by a call to wc, to determine whether a given keyword appears in the query string. It would be easier to just call awk to do that work. But awk is a full-fledged programming language itself, and so that's cheating. If you're going to have awk do all the hard work, this is not really a shell-script program, it's merely a hook into an awk program. But neither grep nor wc is a programming language, so using those tools qualifies this as a shell-script rather than hook to grep script or wc script. But on the other hand, needing to have grep and wc do most of the "real work" shows clearly how sh is merely a scripting language, not a fullfledged programming language.

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
See source.
 

Shell command invokes interpreted program:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
See source.

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See programmer's name
instead of text-fill-in field, for running the same .
See source.
Note that the awk program takes the POSTed encoded-form-contents on standard input, scans it for keywords and makes decisions what to display, and writes to standard output a simple sequence of single-line shell commands, of which all are simply echo 'exactly quoted string' except one which is the date command. That sequence of shell commands is then piped to sh. This is fair, using sh merely to execute one command at a time, not having sh do any decisions. On the other hand, this shows how awk is really flaky as a true programming language. Compare this with the lisp program.

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
Click here to see:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
Click here to see:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
Click here to see:

Put some text here then run my and see what happens.

Here's another form with checkboxes:
See current date&time
See your IP number
See programmer's name
instead of text-fill-in field, for running the same .
Click here to see all the relevant sources.
 
 
 

Index of programs three steps beyond 'Hello World!'

The idea is to actually decode the encoded-form-contents into a table of key-value pairs and use that in the proper way. It doesn't matter how the key-value pairs are stored in your program, so long as the program can perform an arbitrary lookup on a key to find out whether there's any value and if so what that value is. (Note: At this point, keys and values are all strings of characters. Any parsing of strings of digits etc. into numbers etc. would come later.)

Ideally the routine to decode the encoded-form-contents would first check whether the GET or POST method is being used, then fetch the query string for GET or collect standard input for POST as appropriate, then pass the resultant string in a uniform manner to the actual decoder which would work the same way with either method, and build a two-level data structure (such as a association list or hashtable) where keys and values are related in a uniform way regardless of choice of GET/POST method. This general form-decoding routine can then be used in all later examples for the user's client (browser) program to pass data to the server to be processed. But if a program can handle only one of the two methods, or the code is inline instead of a callable subroutine, that's sufficient for initial posting in this section with partial credit.

(Once somebody posts code to fetch at least one environment variable, and use that information to fetch the query string or the contents of standard input to a specified number of characters, and then perform the proper decoding via: (1) ampersand splitting of different key-val pairs, (2) equalsign splitting of key from val within a pair, (3) replace plus signs by spaces, and (4) replace %xx codes with specified characters, it wouldn't be too hard for somebody else to copy that code and repackage it in a more structured way. This section serves two purposes: (a) Show that in a given programming language it's possible at all to collect the encoded form contents and decode them, and (b) Show how to package that utility so that it can be used later.)

To demonstrate that you really have decoded the form correctly and stored the various keys and corresponding values individually, the code can either look for specific keys and perform some operation depending on the corresponding value, a different operation for each specific key, or can issue a report listing all the keys and corresponding values in a nice format. But just a syntax transformation from encoded key-value pairs to report format, such as can be accomplished by Global Replace in sed, is obviously cheating and not what's expected here. Generating the report must actually handle each key individually and perform an actual lookup to get the corresponding value. Since posting the source is required here, it's easy to detect cheaters.
 
php perl lisp c c++ java
On external site: Flaming Thunder

Put some text here and here and here
See current date&time (messy format)
See your browser's IP number
See programmer's name
then run my , invoked by GET method, and see what happens.

Put some text here and here and here
See current date&time (messy format)
See your browser's IP number
See programmer's name
then run the , but invoked by POST method this time (and with additional key=value pairs in query string), and see what happens when there are both query string parameters and POST parameters in the same HTTP transaction.

See source.

.

Put some text here and here and here then run my and see what happens.

Put some text here and here and here then run my and see what happens.

See source.

.

Put some text here and here and here then run my and see what happens.

Note: If you manually type the query string, and it's not in the correct format, the Lisp decoder will display an error message then abort the rest of the output. AFAIK it will not ever crash and thereby invoke a server error.

Put some text here and here and here then run my and see what happens.

See source.

.

Put some text here and here and here then run my and see what happens.

See source.
Warning: I you manually enter the query string, and it's not in exaxctly the right format, the decoder module will crash, and all the key-value pairs, even the ones that were correct, will appear as (null).
(Note: The above program uses an external module written by Peter Burden, posted here, but it had one error causing fatal compiler diagnostic which I needed to fix before the code could be used, and one outright bug (due to operator precedence which he assumed wrongly but never bothered to test) which I needed to fix before the code would work correctly to decode hexadecimal character encodings.)

.

Put some text here and here and here then run my and see what happens.

Warning: This demo has a problem: If the user manually enters the query string, and it's not exactly in the correct format, Stephen Martin's decoder crashes the entire application, causing a "server error". I'd like to find a more robust decoder module.

Put some text here and here and here then run my and see what happens.

See source.
(Note: The above program uses an external module written by Stephen Martin I.T., posted here, then modified by me to generate valid HTML transitional, see my notes here.)

.

Put some text here and here and here then run my and see what happens.

Warning: If the user types the query string manually, and it's not in correct format, the decoder will generate java.util.NoSuchElementException and stop output at that point.

Put some text here and here and here then run my and see what happens.

See source.
 
 
 

Index of programs four or more steps beyond 'Hello World!'

Review / Intro / Private lessons / Non-beginners can skip to final exam / Outline of beginning computer-programming course / Multi-language "cookbook" (started 2007.Jan.26, two chapters mostly finished Jan.30)

Up to this point my emphasis has been on comparing various Web languages according to their ability to go beyond "Hello World" to actually generating live content dependent on realtime environmental information and/or user's selections or other user input. This was mostly to prove that C and the other languages are "true programming languages" whereas text/plain and HTML are not. Note that the true definition of a universal programming language, according to Computer Science experts, is equivalance to a Turing machine, whereby any Turing-machine program can be (rather trivially) emulated by a specific program in any of the programming languages that got to step 3 above, and any program in any such language can (via rather contorted construction) emulated by a Turing-machine program, or equivalently by a starting-tape fed to a universal Turing machine.

So to prove a particular programming language is "universal", we need to write a Turing-machine emulator. However this is not a good practical distinction, because such a machine requires an unlimited amount of memory, which is not possible in this physical universe, so truly speaking none of the languages I've illustrated operating on any exisiting super-distributed-computer, even all the computers in the whole world, would completely qualify. In theory, if there were an unlimited amount of memory available, each step-3 language would qualify, but in practice that's a big if, sigh. So the best we can really do is a "handwave" whereby we try to demonstrate hypothetically that *if* somehow we could build a machine with infinite amount of memory, and *if* we could make a version of such-and-such programming language run on it, and then writing the usual Turing-machine emulator in that language for that machine *then* we somehow convince you it would indeed emulate a true Turing machine. Hopefully if you watch a demo of such a program running on an ordinary finite-memory computer on the net, you'll be convinced of the hypothesis.

So let's take a vote here: How many of you would like to see a collection of implementations of a sorta-Turing-machine (runs like a Turing machine except the tape is finite) in the various step-3 languages, and how many think that would be non-interesting and not worth including here? Contact me with your votes.

Once this distinction (between true programming languages that reached step 3, and not-quite-programming languages that are incapable of reaching that step) was proven, the last step above was to show a general framework for writing server-side Web applications, whereby there's a standard way for decoding a HTML form, whereby any program you write yourself could refer to the contents of the fields of the HTML form and make decisions accordingly, whereby any suitable program you write yourself could be installed as a server-side application. ("Suitable" means it conforms to the back-and-forth transaction-based client/server side, i.e. client fills out form, form contents are submitted to server, server decodes form contents and generates new form which is sent back to client to use next time around the loop.) But all the sample applications given above were rather trivial, such as showing date and time, IP number of your browser, letting user select which trivial results to see and which to omit, or splicing first and last name and favorite number into sentences in various ways. I completely begged the question as to telling how you could write really interesting applications of your own design, which you could then install as server-side Web appliations. That's because the audience for all the above includes people who have never written any software (other than HTML and the like) and don't know how. The instructions I gave above should be sufficient for a non-programmer to copy the sample program to his/her private Web site, set permissions correctly, and voila have his/her very own clone of my demo.

But starting with the next section, I'll outline a course of teaching absolute beginners how to write their very own computer software. There already exist what are called "cookbooks" which tell how to perform basic data-processing tasks in specific programming languages. For example there is online the Common Lisp Cookbook, and available only in book form (pay money to purchase) the perl and java cookbooks. Each "cookbook" deals only with one specific language, breaking the topic down into kinds of d/p tasks at lower levels. I want to instead break down the topics *first* into specific kinds of d/p tasks, and only within each particular task discuss all the different programming languages together as applied to that one task. I intend eventually to write an online emulator that operates in a language-independent way, somewhat like a pocket calculator: You enter raw data whenever you want, whereby different entered values are each stored individually on a stack or other addressible store, and you select various operations to perform on the already-entered values any time you want. But until I can obtain funding to pay for my time writing that emulator, you'll have to wait until I happen to feel like writing some of it without pay, which might take years, or might never occur. With that emulator not yet written, we're at the mercy of existing programming languages. For absolute beginner lessons, writing and debugging one function call at a time, there are only two programming languages that I know of that are suitable: Unfortunately the BeanShell distribution doesn't include documentation of their abstract parse tree, how exactly it's structured, how to traverse such a tree by method calls, so I had to eliminate that as a first-programming language. I really want the student to be able to enter an expression for a parse tree for a micro-program, then execute ("evaluate") that micro-program, and thereby see clearly hands-on the difference between: which sadly is not possible at present in BeanShell. Accordingly, that leaves Lisp as the only suitable language for these lessons.

But just because I'm using Lisp as a teaching tool doesn't mean I'm teaching *only* Lisp. In fact except for the parse tree, I've kept to only the specific data types that are not only available in virtually all modern programming languages but which have literal source-code representations that are virtually the same in all those languages. I include numbers (integers and floats), but without regard to number of available digits that might be different between single and double floats, between short and long integers, between fixnums and bignums, etc. I include strings (vectors of characters), but I don't bother with special characters that need special treatment, such as \" in most languages, \n for newline in C and Java, etc. I wanted to include characters, and in fact did show character objects in CMUCL (CMU Common Lisp), because in Common Lisp they're really nice, with a standard character prefix followed by names for all the special characters, and the character itself for all the regular printable ASCII charactrers. But then I discovered that EMACS Lisp uses integers instead of characters to represent the bytes within a string, so I stopped teaching characters at all. That's fine since all the non-Lisp languages use different notation for characters, and so I really can't teach literal characters in any language-independent way, and maybe it was a bit snobbish to show off how nice characters are in Common Lisp. I already excluded all the other kinds of data objects because even though Common Lisp has literal representations for many of them, the notation is difficult even for me to remember, so in practice I never use a literal constant for any of them. I call make-array instead for example. (Another reason for never using array literals is that with an array you generally do want to modify the elements, which is forbidden within any literal constant, by definition. By comparison, lots of times you really do want to make strings that never will change internally, in fact it's hardly ever that you'd want to modify a string in-place rather than use FORMAT to reassemble pieces from the old string into a new string.) Also it's completely possible to learn how to write computer software, and in fact learn most of the programming techniques, without ever having to use any data structure other than (1) numbers, (2) strings, and (3) linked lists and binary trees all formed from standard pairs. Well, I guess you do want to learn how to use arrays at some point, so I eventually include that, in Lesson 5 (collection objects, and using them to make algorithms more efficient). But I don't confuse the student by mentionning arrays (except strings as vectors of characters) in the early lessons.

When I give private lessons to somebody who has Web access with TELNET available, I connect to my Unix shell account and run CMUCL there, using copy&paste across the connection as a crude pseudo-IDE. When connecting from my home Macintosh over dialup, the copy&paste pseudo-IDE is really quite usable and user-friendly. When connecting from a Windows machine using NotePad as the local repository of things to edit and copy&paste, the cruddy TELNET program requires pulling down a menu and a sub-menu every time we need to paste to the TELNET session, a royal pain, but still it's usable somewhat.

When I give private lessons to somebody who doesn't have TELNET access, when my laptop computer is available, I use GNU EMACS as the IDE for Lisp. EMACS Lisp isn't as nice as Common Lisp, but it's good enough for beginning lessons. The main thing I miss is true character objects, as opposed to integers that represent ASCII values.

If and when I set up a server-side Web application for this purpose, the main evaluation engine will be CMUCL for sure. But I'm just as likely to set up the pocket-calculator application instead, making it totally non-obvious whether Lisp or PHP is doing most of the work behind the scenes. (I like PHP for validating input syntax because it has nice support for regular expressions within a HTML context, whereas with Common Lisp I'd need to wrap an exception-handler around a try of parse-from-string, which is a bit of a crock from one point of view, especially if I'm trying to avoid being specific to any particular programming language.)

So if you've never programmed before and would like to learn, read the outline in the next section and then try to catch me in-person near Sunnyvale, CA. If you already know how to program, please Contact me to arrange to take the "final exam" for this how-to-program course. Your final exam will consist of writing a medium-size application and installing it on your own private CGI or PHP site and telling me where to find it so I can test it to verify it works as required before I set up a link from here to your application.

Here is a preliminary outline of how I plan to present this tutorial material, based on computer-programming lessons I've been giving people in recent years:
 
 
 
Copyright 2004,2005,2007 by Robert Elton Maas, all rights reserved