IDEs - Interactive Development Environments

There is an unfortunate trend in the computer industry to broaden the meaning of technical terms, often to the extent of completely devaluing them.  Perhaps the worst casualty is object-oriented, but interactive development environment is a close contender.

Originally, a development environment was termed interactive if it allowed the programmer to freely switch between entering code and running it, without much ado.  In particular, interactive means that there is no lengthy compile-link-load phase prior to execution, and that any code fragment can be executed, not just the designated main entrypoint for a program.  For example, LISP and classic BASIC provided these features -- albeit in text-based environments.  Interlisp and Smalltalk advanced the state of the art, allowing development to take place without ever having to halt the application under development.  Hypercard brought interactivity to a wider audience.

Alas, interactivity began to be associated with the presence of a graphical user interface.  Microsoft's Hypercard work-alike, Visual Basic, dispensed with most of the interactive features that the original BASIC had.  Borland's various Turbo products, and Microsoft's Visual C adopted the IDE moniker, even though they were all incapable of even running a code fragment, let alone altering a running application.

The 'I' in 'IDE' has become a meaningless adornment,  the adjective interactive a word that can be dropped without changing the meaning of the phrase.  The term IDE is widely used by many (including me) to simply mean 'development environment'

There is hope in sight, however.  The latest versions of Visual Studio and Eclipse promise (or deliver) the ability to "hot-patch" running applications.  They permit (almost) arbitrary functions to be called.  One can hope that soon we will have caught up with the state of the art in 1980...

The following entries will configure Apache (1.3.2) to dump request/reply header information:

#
# Minimal request/reply header logging
#
LogFormat "\n\
\n\
%t %h\n\
%r\n\
Cache-Control: %{Cache-Control}i\n\
Authorization: %{Authorization}i\n\
\n\
%s\n\
Cache-Control: %{Cache-Control}o\n\
Server: %{Server}o\n\
WWW-Authenticate: %{WWW-Authenticate}o\n\
%b" headers
#CustomLog logs/headers.log headers

#
# Full request/reply header logging
#
LogFormat "\n\
\n\
%t %h\n\
%r\n\
Cache-Control: %{Cache-Control}i\n\
Connection: %{Connection}i\n\
Date: %{Date}i\n\
Pragma: %{Pragma}i\n\
Trailer: %{Trailer}i\n\
Transfer-Encoding: %{Transfer-Encoding}i\n\
Upgrade: %{Upgrade}i\n\
Via: %{Via}i\n\
Warning: %{Warning}i\n\
Accept: %{Accept}i\n\
Accept-Charset: %{Accept-Charset}i\n\
Accept-Encoding: %{Accept-Encoding}i\n\
Accept-Language: %{Accept-Language}i\n\
Authorization: %{Authorization}i\n\
Expect: %{Expect}i\n\
From: %{From}i\n\
Host: %{Host}i\n\
If-Match: %{If-Match}i\n\
If-Modified-Since: %{If-Modified-Since}i\n\
If-None-Match: %{If-None-Match}i\n\
If-Range: %{If-Range}i\n\
If-Unmodified-Since: %{If-Unmodified-Since}i\n\
Max-Forwards: %{Max-Forwards}i\n\
Proxy-Authorization: %{Proxy-Authorization}i\n\
Range: %{Range}i\n\
Referer: %{Referer}i\n\
TE: %{TE}i\n\
User-Agent: %{User-Agent}i\n\
\n\
%s\n\
Cache-Control: %{Cache-Control}o\n\
Connection: %{Connection}o\n\
Date: %{Date}o\n\
Pragma: %{Pragma}o\n\
Trailer: %{Trailer}o\n\
Transfer-Encoding: %{Transfer-Encoding}o\n\
Upgrade: %{Upgrade}o\n\
Via: %{Via}o\n\
Warning: %{Warning}o\n\
Accept-Ranges: %{Accept-Ranges}o\n\
Age: %{Age}o\n\
ETag: %{ETag}o\n\
Location: %{Location}o\n\
Proxy-Authentication: %{Proxy-Authentication}o\n\
Retry-After: %{Retry-After}o\n\
Server: %{Server}o\n\
Vary: %{Vary}o\n\
WWW-Authenticate: %{WWW-Authenticate}o\n\
%b" full-headers
#CustomLog logs/full-headers.log full-headers

Franz' ACL 5 has an interesting 'gotcha' related to backquote syntax.  Consider this form:

`(:a ,x :b ,y :c nil)

The list returned is not entirely fresh.  In fact, the last two conses comprise a constant list.  Therefore, if you destructively alter the last element, all lists generated from this form will be updated.  Ouch.  I am not sure whether this behaviour conforms to ANSI or not (I haven't looked).

I discovered a problem with our ORACLE.C module while working on ITEMSEQ.  If you use bind variables in an SQL statement (e.g. an INSERT statement), our call to OEXEC hangs indefinitely.  At first, I was concerned that the problem existed only in LISP.  But I wrote a small C program that called ORACLE.C directly, and it exhibited exactly the same behaviour.  It made no difference whether blocking was turned on or off.  When turned off, OEXEC always returns the 'would block' error code.  I am stumped as to why this behaviour occurs.  Perhaps it has something to do with the fact that we are using the old, old, old, OCI interface.  Oracle may no longer support that interface.  Bind variables do seem to work for queries.