Index of Hello World! programs and beyond

Table of contents:

The classic standalone 'Hello World!' program
- In separate file, parallel track from this file: WAP (Wireless Access Protocol) for cellphones steps 0 thru 3
All examples below in this document are for Desktop/Laptop browsers and will not necessarily work with cellphones using WAP.
My conversion of 'Hello World' to be Web-accessible
txt t/h html php sh* perl python lisp awk f77 c c++ ft java
One step beyond (non-static, output varies with time or IP number)
php sh* perl python lisp c c++ ft java
Two steps beyond (responsive, output depends on user input)
html / php sh* perl lisp awk c c++ ft java
Three steps beyond (proper decoding of HTML-form contents, so that program can be correctly responsive to user input)
php perl lisp c c++ java
On external site: ft
Four or more steps beyond (see link to multi-language "cookbook" (work in progress): exploration of different types of data available in various programming languages, and how to perform common manipulations on such datatypes, contrasting how to do the same operation on equivalent data using different programming languages; also related topics covered in this document:)
Review / Intro / Private lessons / Non-beginners can skip to final exam / Outline of beginning computer-programming course

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:

The ACM collection claims to have source listings in just over 200 languages. (I didn't feel like counting to verify that figure.)
Scott Moore was kind enough to show me the WikiPedia site for 'Hello World' programs, which has another big list of Hello World programs in various languages, again nothing online or Web accessible, just source listings, like the ACM list. The WikiPedia WebPage also has links to three other Hello World collections:
cuillin (UK) Update 2007.Jan.26: When I tried this site just now, for the first time in months, the host was unavailable. Does anybody know what happened to this site?
wolfram (Germany)
esoteric Update 2007.Jan.26: When I tried this WikiPedia page just now, for the first time in months, the WebPage no longer exists, and a search for it failed to turn it up. Does anybody know what happened to this page?
Update 2007.Dec.02: Ian Osgood told me about a new location for such a collection on esolangs.org.

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:

I took care to make these programs produce output suitable for viewing on the Web, including the HTTP/MIME header for either text/plain or text/html.
My programs are set up for you to actually run, live on my ISP's Web server, any time you want, and in each case I provide a live CGI/shell script you can run to see the actual files in place where they are running and the directory permissions needed to make them usable on the Web.
My standards for inclusion here are a "level playing field": Every program must exist on an accessible CGI-BIN or other Web-accessible directory, and must somehow actually work via a CGI or other URL, as contrasted with other situations such as the IBM 1401 card (in one of the traditional-Hello-World collections) which you must physically load into the card reader (which hasn't existed for at least 20 years), or the keys you must type into a calculator. As a result, you can directly compare different programming languages for their ability to do almost exactly the same thing under similar conditions.

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;

the shell-script interface between CGI and the CMUCL environment where the CL source is loaded and run
the source of the CL program (which is run interpreted here)
directory entries for both the above files

awk program
Click here to see;

the shell-script interface between CGI and the awk environment where the awk source is interpreted
the source of the awk program (which is run interpreted here)
directory entries for both the above files

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

Fortran-77 program
Click here to see:

the source program
directory entry for it
directory entry for compiled object program after renaming

C program
Click here to see:

the source program
directory entry for it
directory entry for compiled object program after renaming

C++ program
Click here to see:

the source program
directory entry for it
directory entry for compiled object program after renaming

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

the source program
directory entry for it
command for compiling it
directory entry for compiled object program

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:

the shell-script interface between CGI and the Java virtual machine running the byte-compiled Java class
the source of the Java class
directory entries for all three files (shell-script / Java-source / compiled-Class)

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:

date&time as an associative array
the IP number of your browser embedded in sentence
the value of the PATH variable in the CGI environment embedded in sentence
Appx. 18 screens or 9 full 11-inch pages of details about PHP implementation on this server and current state of environment variables etc.

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:

date&time as given by the Unix 'date' command emitted directly on line by itself
the IP number of your browser embedded in sentence via 'echo' command
the value of the PATH variable in the CGI environment embedded in sentence via 'echo' command

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:

date&time as given by the Unix 'date' command embedded in a sentence instead of on a line by itself, to show the ability to store a value in a variable and then trim off the newline before printing
the IP number of your browser embedded in sentence just like the shell script
the value of the PATH variable in the CGI environment embedded in sentence just like the shell script

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:

Both GMT and local (California) time as numeric fields in vector.
the IP number of your browser embedded in sentence just like the shell script
the value of the PATH variable in the CGI environment embedded in sentence just like the shell script

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:

the shell-script interface between CGI and the CMUCL environment where the CL source is loaded and run
the source of the CL program (which is run interpreted here)
directory entries for both the above files

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:

the source program
directory entry for it
directory entry for compiled object program after renaming

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:

the source program
directory entry for it
directory entry for compiled object program after renaming

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:

the source program
directory entry for it
compilation instructions
directory entry for compiled object program

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:

the shell-script interface between CGI and the JVM where the compiled java program is loaded and run
the source of the java program (which must be compiled before running)
directory entries for both the above files

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:

See source.

Inline interpreted scripts:

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.

See source.

Shell command invokes interpreted program:

See source.

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.

Click here to see:

the source program
directory entry for it
directory entry for compiled object program after renaming

Click here to see:

the source program
directory entry for it
directory entry for compiled object program after renaming

Click here to see:

the source program
directory entry for it
command to compile it
directory entry for compiled object program

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

See source.

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.

See source.

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.)

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.

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.)

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.

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:

Lisp, with stdio read-eval-print loop (common lisp only) or with EMACS-style IDE (emacs-lisp a.k.a. elisp, or common lisp)
Java, with BeanShell, directly or via GNU EMACS FIFO link

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:

literal constants
symbols which act as names of variables
function call forms
program-control forms (sequences, alternatives, loops)

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:

Lesson 1: Syntax for representing individual data-values:
- Numbers (integers, common fractions, decimal fractions)
- Strings (finite sequences of characters, inside quote marks)
- Symbols
- Lists (finite sequences of any data-values, inside parens)
  - (Nested lists (with lists inside (with more inside)))
Lesson 2: What happens when data-value is used as Lisp program:
- Literal constant (number or string) -- Result is same value back again.
- Name of variable (symbol by itself) -- Result is latest assigned value of variable, or undefined/unbound-variable exception/error if symbol doesn't yet have a value assigned to it.
- Assignment of value to a variable, so that you won't get unbound-variables exceptions next time you ask for its value.
- Function-call form (list whose first element is a symbol) -- Each of the other elements is run as a tiny program, and each of their individual results collected, then the named function is called with those results as its parameters.
  - Sample: A few useful functions for processing numeric and string data-values.
  - Simple usage: Using literal constant as parameter (argument) to function.
  - Simple usage: Using retrieved value of variable as parameter (argument) to function.
  - Combined variable assignment and function call: Calling a function as before, but then assigning the result to a variable (symbol) instead of just looking at it and then discarding it.
  - Nested usage: Using return value from function as parameter to other function.
  - Undefined function exception/error: If you try to use a list whose first element doesn't currently name a function.
Lesson 3: Putting micro-programs in sequence to do multi-step D/P (data processing), and building such sequences into named functions
- Why do we need more than one function call to do the whole job?
  - Top-down design: Think of a task we'd like to accomplish, but which is too complicated to accomplish in a single step. Think of how to break it down into medium-size pieces, and how to break each of those down into small-size pieces, each of which accomplshed by calling some combination of existing functions.
  - Bottom-up tool-building: Think of the smallest useful and meaningful part of the overall desired task, which can be built by combining just a few simple function calls.
  - Input-forward unit-testing: What data do we have already or which we can easily generate? What single function call will convert that data into something closer to our low-level next-goal? Try it! If it works, save that single function-call for re-use.
    - Rule#1: Don't move on to the next step until you have the current/latest step tested sufficiently to be reasonably sure you have it implemented correctly or nearly so.
    - Rule#2: If you just can't get a particular step working, post a question telling what you have so-far and how you're stuck. While waiting for a response, think of some *other* sub-task where you also have all the input data available so you could switch to working on that task until you get help so that this task becomes unblocked.
- Manual sequencing: Successively running one micro-program after another, where results from early micro-programs (stored as values of named variables) are used as (input) parameters for later micro-programs.
- FORMAT: Formatted output, very useful aid to debugging everything that follows in this lesson.
- PROGN: Simple sequencing, all variables still global.
- PROG: Simple sequencing, now able to make variables local.
- IF: Simple condition-test with alternate single steps.
- COND: Complex chained (if-then-else-if...) condition-tests with alternate multi-step sequences.
- GO: Simple program loops within a PROG.
- RETURN: Breaking out of a PROG to return a non-null result.
- DEFUN: Defining a named function which you can call later. -- Now you have a tool you can use to build larger tools, all the way up to the toplevel task you want accomplished.
Lesson 4: Refactoring syntax: Getting rid of most uses of GO in PROG.
- Containers&Collections: Places to store&change values other than just simple variables (symbols)!
- Mapping functions: Apply same function to each element of sequence.
- Anonymous functions and lexical closures: Make up, on the fly, your own custom nameless function to pass to mapping functions, so that they can refer to static values that aren't in the sequence being mapped.
- The new LOOP macro.
- Enumerations, virtual enumerations, and other continations.
Lesson 5: Refactoring algorithms: Devising data structures that make D/P much more efficient than brute-force processing of flat data sequences.
- Common types of collection objects:
  - Frameworks: array/vector, linked-list, sorted-binary-tree, heap-tree (priority queue), hash-table
  - Elements: single key or value in set, key-value pair in map
- Common algorithms for collection objects:
  - Linear search (find needle in any sequence)
  - Sort (rearrange into correct sequence)
  - Merge/collate (two already-sorted sequences)
  - Binary search (quickly find needle in already-sorted sequence)
  - Maintain sorted & balanced binary tree (AVL or other)
  - Searching & update within binary tree
- The important distinction between a tree viewed as a set of independent nodes that point to each other, whereby arbitrary sub-trees can be shared, and a tree viewed as a single collection object with clear distinction what part of the structure is the framework and what part are the elements, whereby only elements can ever be shared.
- Enumerations and other continations.
Final exam at this point. Skip to language-independent course now if you don't want to get involved in debates over which programming language is "best" in each person's opinion. Jump back here to pick-up the discussion after you've had some hands-on practice with various different programming languages.
Lesson 6: Briefly comparing the various programming languages
- Why ever use another language except Lisp?
  - Perl has good support for regular expressions
  - Perl is the only server-side programming language supported on some free Web-hosting services such as Tripod.
  - PHP is the only server-side programming language supported on some other free Web-hosting services such as 5gbfree.
  - Java has good support for standard collection objects
  - Many Web broswers support Java applets and/or JavaScript for client-side utilities
  - Perl and PHP and Java Server Pages (JSP) support text-mostly server-side applications with tiny scriptlets to generate output spliced among the bulk of verbatim HTML text.
  - Java has good support for GUI.
  - Java has good support for XML.
  - C supports generation of system-level machine code for operating-system kernels
  - Java/BeanShell has a nice class-browser built-in, including not just the vendor-supplied API but all your own software accessible via classpath
  - Java API is nicely documented online, in a form slightly easier to use than the Common Lisp HyperSpec.
  - Depending on the local configuration, Perl or PHP or Java/J2EE etc. might be integrated into the server to avoid spawning a new process for each client connection.
- Why ever use another dialect of Lisp except for Common Lisp?
  - Emacs lisp has powerful utilities for processing text in an editor environment, and is fully integrated into Emacs (in fact most of Emacs is written in Emacs lisp). Emacs provides a nice IDE for developing Emacs lisp software.
  - Scheme is much smaller than Common Lisp and hence easier to completely understand.
  - But for writing general-purpose data-processing applications, especially CGI-server applications, Common Lisp is the only reasable choice, IMO.
- Writing some GUI applications with Java/BeanShell.
- Writing some CGI applications with any language of your choice among those which achieved three steps beyond CGI-hello-world earlier. (But I personally recommend against C or C++ for such use.)
- How the available data-types compare between languages
- How the available utilities compare between languages
- An online framework for developing D/P software independent of any particular programming language, generating language-specific syntax only when actually requested. (Not yet written, I would like some funding!)

免责声明:
当前网页内容, 由大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com

订阅 substack 体验古早写作:

点击注册~> 获得 100$ 体验券:

关注公众号, 持续获得相关各种嗯哼:
zoomquiet

自怼圈/年度番新

关于 ~ DebugUself with DAMA ;-)