Re: Programming Languages for Technical Communication

[Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM>]

-----Original Message-----
From: Mark Baker <mbaker -at- OMNIMARK -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>


>This misses the point. I am not arguing that you need programming skills to
>create tools to create information products. I am arguing that information
>products themselves are now aquiring behavior; the ability to respond to
>user input and stored information about the user and to customize
>information for that user. This means that information products are
becoming
>programs (rather than just data) and that writing and programming are


Neither am I arguing that TWs will need/use programming skills to create
tools to create info products. My point is that tools tend to evolve so that
the user spends less time manipulating the tool and more time solving the
problem.

My previous post mentioned Word/WordPerfect as an example. Here's another
one: During the 80's, I did significant amounts of writing for IBM. In the
early-to-mid 80s, I used an IBM internally recognized markup language called
ISIL to generated printed material. After four or five releases of ISIL, it
evolved into BookMaster, which IBM marketed as a product--along with other
tools in its 'Master series--during the late 80s. BookMaster was huge: a
highly evolved general markup language with tons of capabilities and
features. It only had one problem: it required the user to understand
programming techniques like syntax, compiling, and debugging. I literally
spent hundreds of hours helping my writers learn that tool, which they
resisted because they knew WYSIWYG products could do the same thing. I also
spent hundreds of hours debugging their problems when the SCRIPT compiler
yakked at them. My writers were spending more time working on BookMaster
codes than they did their writing.

BookMaster is now a little-known product that is probably only used by huge
companies who still maintain documentation on a mainframe. Overall, GML-like
tools have been supplanted as the tool of choice for printed materials by
Word, Frame, Ventura, PageMaker ... all WYSIWYG tools.

But we're seeing a similar cycle with HTML. HTML, which is another general
markup language similar to BookMaster, requires significant effort to code,
test, and verify in several browsers. (BTW, HTML isn't nearly as full
featured as BookMaster. IMHO, BookMaster was a grandaddy! It could do
anything you wanted if you knew the code!) We have only begun to see tools
eliminate the complexities of HTML, allowing the writer to concentrate on
the work (not the tool). I predict that eventually the tools will virtually
eliminate the need to hand-code or even "tweak" HTML code.

Many people consider me a tool wizard. I've used a text editor many times
throughout my career to code software in various languages, ISIL,
BookMaster, IPF (OS/2's online help tool), RTF, WinHelp, SGML, and HTML .
But frankly, I don't get my kicks out of hand coding. It's an inefficient
use of my time, so I'm always looking for a good WYSIWYG.

>equally necessary skills in creating them. Unlike the trend to WYSIWYG in
>data manipulation tools, atempts to create visual programming tools have
met
>with no significant success, except for UI building. Programming logic is
>still written in text editors and there is no reason to suppose it will not
>contine to be. Even if visual programming tools were to take over, however,
>the skills of programming -- designing appropriate application logic and
>data structures -- would still be required.

You're right--there are many tasks that cannot be relegated to a tool. When
I code C++ (using Visual C++), there is nothing in the Visual C++ tool that
will help me generate a specific SQL query or calculation or data structure.
That, as you say, comes from my business knowledge and experience, not the
tool. The tool does, however, significantly ease building a GUI and hooking
it to the underlying code. Have you ever written a GUI without prepackaged
controls and window structures? I used to write BASIC apps that ran in DOS.
Often the code for the business logic would be insigificant compared to the
code required to put up the user interface. For example, the code required
to calculate the amortization of a mortgage consisted of only a few lines
compared to interface code required to collect the info and display the
results.

>Writers who cannot write non-linear material will be at the worst deficit.
>We have had paper as the sole significant medium for so long we tend to
>identify writing for paper with writing itself. Writers in the future are
>going to have to design the data structures of content management systems
>and then write the information components that populate those structures.


As you suggest, doing this requires two sets of skills: (1) writing
nonlinear material and (2) pouring that material into presentation medium. I
argue that the writer should concentrate on the first skill because tools
will evolve that take care of the second skill.

Regards...Kris
------------------------------
kolberg -at- actamed -dot- com
kris -at- olberg -dot- com