[6593] in Perl-Users-Digest
Perl-Users Digest, Issue: 218 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 2 02:38:11 1997
Date: Tue, 1 Apr 97 23:00:15 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 1 Apr 1997 Volume: 8 Number: 218
Today's topics:
FREELANCE CGI PROGRAMMER NEEDED dave@dzn.com
Re: Ousterhout and Tcl lost the plot with latest paper <Chris.Bitmead@alcatel.com.au>
Re: Unix and ease of use (WAS: Who makes more ...) (Terry Reedy)
Re: Using Perl with MS-Access albert_b@pacbell.net
Re: Where do I get 'h2n' perl script for unix <brendon@conibm.aldis.com.au>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 02 Apr 1997 00:21:21 -0600
From: dave@dzn.com
Subject: FREELANCE CGI PROGRAMMER NEEDED
Message-Id: <859961420.24151@dejanews.com>
I need a mortgage prequalifying script. Off the shelf script that you can
modify you be preferred. Need is immediate.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: 02 Apr 1997 15:57:57 +1000
From: Chris Bitmead <Chris.Bitmead@alcatel.com.au>
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <s6y208um0ey.fsf_-_@aalh02.alcatel.com.au>
chen@adi.COM (Franklin Chen) writes:
> I've looked at the paper, and found it extremely misleading for its
> omissions and factual inaccuracies. In particular, I was baffled that
> there was no mention _whatsoever_ of advanced languages such as
> Scheme, ML, and Haskell--languages that to me seem most promising as
> foundations for safe, efficient, and expressive prototyping/scripting
> as well as general purpose programming.
>
> If anyone is interested, I can go into detail about everything I found
> misleading about Ousterhout's paper. I encourage anyone else who
> cares to do the same; perhaps an eventual unified response to
> Ousterhout is called for.
The essence of Ousterhout's argument seems to be this... What is the
ultimate sports car (programming language)? A '59 Cadillac complete
with fins and powerful engine (C++) or a VW beetle with it's elegant
simplicity (Tcl). John puts forward a strong argument that the beetle
is the ultimate sports car, while conveniently ignoring that it is
possible to combine the powerful engine of the Caddy with the elegance
of the VW and come up with a Porche 959 (Scheme or Lisp or ML or many
others).
These are my comments on his paper. Remember that Sun is pushing Tcl
for some obscure reason, and Ousterhout is apparently working for Sun
now, so I guess we'd expect something like this, but we can't let him
get away with this. Imagine... C and TCL. The worst of all possible
worlds.
My comments are interspersed with his paper below...
>Scripting: Higher Level Programming
> for the 21st Century
> John K. Ousterhout
>
> Abstract Scripting languages such as Visual Basic and Tcl
>represent a very different style of programming than system
>programming languages such as C or Java. Scripting languages are
>designed for "gluing" applications; they use typeless approaches to
>achieve a higher level of programming and more rapid application
>development than system programming languages. Increases in computer
>speed and changes in the application mix are making scripting
>languages more and more important for applications of the
>future. Whereas object-oriented approaches have largely failed to
>increase software reuse or reduce development costs, scripting
>languages have succeeded.
>
>1 Introduction
>
>As we near the end of the 20th century a fundamental change is
>occurring in the way people write computer programs. The change is a
>transition from system programming languages such as C or C++ to
>scripting languages such as Visual Basic or Tcl. Although many people
>are participating in the change, few people realize that it is
>occurring and even fewer people know why it is happening. I am writing
>this paper to call attention to the change and to explain why
>scripting languages will handle many of the programming tasks of the
>next century better than system programming languages.
>
>Scripting languages are designed for different tasks than system
>programming languages, and this leads to fundamental differences in
>the languages. System programming languages were designed for
>building data structures and algorithms from scratch, starting from
>the most primitive computer elements such as words of memory. In
>contrast, scripting languages are designed for gluing: they assume the
>existence of a set of powerful components and are intended primarily
>for connecting components together. System programming languages are
>strongly typed to help manage complexity, while scripting languages
>are typeless to simplify connections between components and provide
>rapid application development.
>
>Scripting languages and system programming languages are
>complementary, and most major computing platforms since the 1960's
>have provided both kinds of languages. However, several recent trends,
>such as faster machines, the increasing importance of graphical user
>interfaces and component architectures, and the growth of the
>Internet, have greatly increased the applicability of scripting
>languages. These trends will continue over the next decade, with
>scripting languages used for more and more applications and system
>programming languages used primarily for creating components.
>
>2 System programming languages
>
>In order to understand the differences between scripting languages and
>system programming languages, it is important to understand how system
>programming languages evolved. In the earliest days of computing,
>computers were programmed by entering instructions and data directly
>into the computer in binary form. This approach was quickly replaced
>by symbolic assembly languages. Assembly languages represent a program
>textually with one statement for each machine instruction. The fields
>of the instruction are specified symbolically: for example, the symbol
>ADD might be used to represent the opcode for an addition instruction
>and SP might be used to specify the register that serves as stack
>pointer. An assembler reads the statements, converts symbols to the
>corresponding binary values, and generates a binary program suitable
>for execution.
>
>The use of textual symbols in assembly language makes programs
>substantially easier to write than binary approaches while still
>providing complete control over the machine. However, assembly
>language suffers from three defects. First, it requires the programmer
>to write one line of code for each instruction or variable, which
>becomes tedious as programs grow in size. Second, assembly language
>forces programmers to deal with many low-level details such as
>register allocation and procedure calling sequences. Third, assembly
>language provides almost no structure; for example, all instructions
>have roughly the same appearance and integer and floating-point
>variables are declared in the same way. As a result, it is difficult
>to write and maintain large programs in assembly language.
>
>By the late 1950's higher level languages such as Fortran and Algol
>began to appear. In these languages statements no longer correspond
>exactly to machine instructions; a compiler translates each statement
>in the source program into a sequence of binary instructions. Over
>time a series of system programming languages evolved from Algol,
>including such languages as PL/1, Pascal, C[4], C++[7], and
>Java[1]. System programming languages allow large applications to be
>developed much more quickly than assembly languages while providing
>nearly the same level of efficiency. As a result, they have almost
>completely replaced assembly language for the development of large
>applications.
A brave beginning! Ousterhaut tries to characterise Tcl as some sort
of next generation language that is some sort of higher level
abstraction above non-scripting languages.
Talk about turning a bug into a feature! Apparently because Tcl lacks
fundamental language concepts such as data structures, and a type
system, it is now superior because it is "simple". I guess that makes
BASIC another superior language of the future. NOT!
>System programming languages differ from assembly languages in two
>ways: they are higher level and they are strongly typed. The term
>"higher level" means that many details are handled automatically so
>that programmers can write less code to get the same job done. For
>example:
Where did this very dubious definition of a "system programming
language" come from?? I don't think there is any official definition,
but these are the attributes I personally would use to describe a
systems language. They certainly don't include Ousterhout's
definition...
A system programming language should be...
* Capable of being compiled for efficiency
* Suitable for building complex data structures and algorithms.
* Suitable for accessing the full capabilities of the operating
system in a convenient fashion.
> Register allocation is handled by the compiler so that
>programmers need not write code to move information between registers
>and memory. Procedure calling sequences are generated automatically
>so that programmers need not worry about moving arguments to and from
>the call stack. Programmers can use simple keywords such as while and
>if for control structures; the compiler generates all the detailed
>instructions to implement the control structures.
>
>On average, each line of code in a system programming language causes
>about five machine instructions to be executed, compared to one
>instruction per line in assembly language.
And then Ousterhout goes on to argue that because a one line Tcl
command can create a GUI button, therefore it is a higher level
language. What a lot of rot! One line of C code can cause 10 billion
instructions to be executed if it is a function call. And the Tcl
button creation command is basicly a function call. Absolutely no
difference. Very misleading.
>Various studies have shown
>that programmers can write roughly the same number of lines of code
>per year regardless of language[2], so system programming languages
>allow applications to be written much more quickly than assembly
>languages.
>
>The second difference between assembly languages and system
>programming languages is typing. The term "typing" refers to the
>degree to which the meaning of information is specified in advance of
>its use.
Ousterhout conveniently excludes the whole spectrum of dynamically
typed languages, not to mention strongly typed languages with type
inference like ML.
>In a strongly typed language the programmer declares how each
>piece of information will be used and the language prevents the
>information from being used in any other way. In a weakly typed
>language there are no a priori restrictions on how information can be
>used: the meaning of information is determined solely by the way it is
>used, not by any initial promises.
A fairly vague assertion, which he continues to repeat over and over
without examples.
>Modern computers are fundamentally typeless at heart: any word in
>memory can hold any kind of value, such as a character, an integer, a
>pointer, or an instruction. The meaning of a value is determined by
>how it is used: if the program counter points at a word of memory then
>it is treated as an instruction; if a word is referenced by an integer
>add instruction then it is treated as an integer; and so on. The same
>word can be used in different ways at different times.
Modern computers are not "typeless"! While I find this whole argument
meaningless anyway, if you want to make the comparison, you would say
that computers are dynamically typed, but nevertheless typed. In that
respect they compare better to dynamically typed languages like
Lisp. While a piece of computer memory can hold data of any type,
(Like a lisp variable), computer instructions only operate on the
correct type. You can't use an add instruction and pass it a string
with some ascii numbers in it (Similar to Lisp).
>Today's system programming languages are strongly typed. For example:
Are they? First Ousterhout defines a strongly typed languages as
system programing languages. Now he tells us that systems languages
are strongly typed. Well I guess if you define it that way in advance
it must be so.
> Each variable in a system programming language must be declared
>with a particular type such as integer or pointer to string, and it
>must be used in ways that are appropriate for the type. In assembly
>languageany variable can be used in any way. Data and code are
>totally segregated in system programming languages, whereas they are
>interchangeable in assembly languages; it is difficult or impossible
>to create new code on the fly in a system programming language.
>Variables can be collected into structures or objects with
>well-defined substructure and procedures or methods to manipulate
>them; an object of one type cannot be used where an object of a
>different type is expected.
>
>Typing makes large programs more manageable by clarifying how things
>are used and differentiating between things that must be treated
>differently. Compilers can use type information to detect certain
>kinds of errors, such as an attempt to use a floating-point value as a
>pointer.
>
>To summarize, system programming languages are designed to handle the
>same tasks as assembly languages, namely creating applications
>starting from scratch. System programming languages are somewhat
>higher level and much more strongly typed than assembly
>languages. This allows applications to be created more rapidly and
>managed more easily with only a slight loss in performance. See Figure
>1 for a graphical comparison of binary code, assembly language, and
>several system programming languages.
>
>
>3 Scripting languages
>
>Scripting languages such as Perl[8], Tcl[6], Visual Basic, and the
>Unix shells represent a very different style of programming than
>system programming languages. Scripting languages assume that there
>already exists a collection of useful components written in other
>languages. Scripting languages aren't intended for writing
>applications from scratch; they are intended primarily for plugging
>together components. For example, Tcl and Visual Basic are used to
>arrange collections of user interface controls on the screen while
>Unix shell scripts are used to assemble filter programs into
>pipelines. Scripting languages are often used to extend the features
>of components but they are rarely used for complex algorithms and data
>structures; features like these are usually provided by the
>components. Scripting languages are sometimes referred to as glue
>languages or system integration languages.
>
>In order to simplify the task of connecting components, scripting
>languages tend to be typeless: all things look and behave the same so
>that they are interchangeable. For example, in Tcl or Visual Basic a
>variable can hold a string one minute and an integer the next. Code
>and data are often interchangeable, so that a program can write
>another program and execute it on the fly. Scripting languages are
>often string-oriented, since this provides a flexible representation
>for many different things.
As we all know, "proper" programming languages like Lisp can also
generate and execute code on the fly. What Lisp programmers also know
is that in most situations, doing so is a sign of a bad design. In the
case of Tcl, the ability to do so is just a band-aid for the
limitations of the language, that Lisp style languages generally don't
need, but nevertheless do have.
>A typeless language makes it much easier to hook together
>components. There are no a priori restrictions on how things can be
>used, and components and values are represented in a uniform
>fashion. Thus any component or value can be used in any situation;
>components designed for one purpose can be used for totally different
>purposes never foreseen by the designer. For example, in the Unix
>shells, all filter programs read a stream of bytes from an input and
>write a string of bytes to an output so any two programs can be
>connected together simply by attaching the output of one program to
>the input of the other.
>
>The strongly typed nature of system programming languages discourages
>reuse. Programmers are encouraged to design a variety of incompatible
>interfaces. Each interface requires objects of specific types and the
>compiler prevents any other types of objects from being used with the
>interface, even if that would be useful. In order to use a new object
>with an existing interface, conversion code must be written to
>translate between the type of the object and the type expected by the
>interface. This in turn requires recompiling part or all of the
>application, which isn't possible in the common case where the
>application is distributed in binary form.
A fairly poor attempt to gloss over the issues here. Converting
everything to strings does not solve anything except in the most
trivial cases. Just because you encode some complex concept into a
single string doesn't mean that the type information isn't still
there. The simplest case is of course passing a string to an add
function. At run time you've still got to know that the string
contains a number. Again Ousterhout conveniently ignores the
dynamically typed languages and glosses over the real issues.
>To see the advantages of a typeless language, consider the following
>Tcl command:
>
>button .b -text Hello! -font {Times 16} -command {puts hello}
>
>This command creates a new button control that displays a text string
>in a 16-point Times font and prints a short message when the user
>clicks on the control. It mixes six different types of things in a
>single statement: a command name (button), a button control (.b),
>property names (-text, -foreground, and -command), simple strings
>(Hello! and hello), a font name (Times 16) that includes a typeface
>name (Times) and a size in points (16), and a Tcl script (puts
>hello). Tcl represents all of these things uniformly with strings. In
>the button example the properties may be specified in any order and
>unspecified properties are given default values; more than 20
>properties were left unspecified in the example.
>
>The button example requires about 25 lines of code in three procedures
>when implemented in C++ with Microsoft Foundation Classes. Just
>setting the font requires 7 lines of code:
>
>LOGFONT lf;
>
>memset(&lf, 0, sizeof(lf));
>
>lf.lfHeight = -16;
>
>strcpy(lf.lfFaceName, "Times New Roman");
>
>CFont *fontPtr = new CFont();
>
>fontPtr->CreateFontIndirect(&lf);
>
>buttonPtr->SetFont(fontPtr);
Come on! All this shows is the inconveniece of using the MFC
classes. An interface exactly the same as the Tcl one could easily be
written in C++.
>Almost all of this code is a consequence of the strong typing:
>variables lf and fontPtr must be declared, fields in the font
>descriptor structure lf must be filled in individually, then a new
>object of type CFont must be created from lf in order to match the API
>of the button's SetFont method. In Tcl, the essential characteristics
>of the font (typeface Times, size 16 points) can be used immediately
>with no declarations, intermediate structures, or
>conversions. Similarly, in C++ the behavior for the button must placed
>in a separately declared method, whereas in Tcl it can be included
>directly in the command that creates the button.
>
>It might seem that the typeless nature of scripting languages could
>allow errors to go undetected, but in fact scripting languages are
>just as safe as system programming languages. For example, an error
>will occur if the font size specified for the button example above is
>a non-integer string such as xyz.
Huh??? Presumably he is refering to the line...
lf.lfHeight = -16;
Surely this would give a type error if it were changed to...
lf.lfHeight = "xyz";
>The difference is that scripting
>languages do their error checking at the last possible moment, when a
>value is used. Strong typing allows errors to be detected at
>compile-time, so the cost of run-time checks is avoided. However, the
>price to be paid for this efficiency is more conservative restrictions
>on how information can be used: this results in more complex and less
>flexible programs.
>
>Another key difference between scripting languages and system
>programming languages is that scripting languages are usually
>interpreted whereas system programming languages are usually
>compiled.
"Usually" perhaps, but not always. Surely the best solution is a
language which can easily accomodate both options? Tcl does not at all
easily support compilation. C++ does not easily support
interpretation. There are many languages which readily support both.
>Interpreted languages provide rapid turnaround during
>development by eliminating lengthy compile times. Interpreters also
>allow powerful effects to be achieved by generating code on the
>fly. For example, a Tcl-based Web browser can parse a Web page by
>translating the HTML for the page into a Tcl script using a few
>regular expression substitutions. It then executes the Tcl script to
>render the page on the screen. Or, an application can be extended by
>downloading code into it.
>
>Scripting languages tend to be less efficient than system programming
>languages, in part because they use interpreters instead of compilers
>but also because their basic components are chosen for power and ease
>of use rather than an efficient mapping onto the underlying
>hardware. For example, scripting languages tend to use variable-length
>strings in situations where a system programming language would use a
>binary value that fits in a single machine word, and scripting
>languages often use hash tables where system programming languages use
>indexed arrays.
But why? If we accept that scsh is a scripting language (which clearly
it is), it suffers from neither of these drawbacks.
>Fortunately, the performance of a scripting language isn't usually a
>major issue. Applications for scripting languages are generally
>smaller than applications for system programming languages, and the
>performance of a scripting application tends to be dominated by the
>performance of the components, which are typically implemented in a
>system programming language.
This is an often put forward argument that falls over time and time
again when reality hits. Applications might start off small, but then
people want more features, more performance, more
everything. Eventually using the poor scripting languages break down
because they don't give you the performance or data structures or
abstraction mechanisms to support what you're doing. Things become
more and more messy. You keep having to go back and rewrite things in
your "systems" languages.
Sure Tcl and C can be a lot faster than C alone. But then C is an
appalling benchmark against which to make judgements.
>Scripting languages are higher level than system programming
>languages, in the sense that a single statement does more work on
>average. A typical statement in a scripting language executes hundreds
>or thousands of machine instructions, whereas a typical statement in a
>system programming language executes about five machine
>instructions. Part of this difference is because scripting languages
>use interpreters, which are less efficient than the compiled code for
>system programming languages. But much of the difference is because
>the primitive operations in scripting languages have greater
>functionality. For example, in Perl it is about as easy to perform a
>regular expression substitution as it is to perform an integer
>addition. In Tcl, a variable can have traces associated with it so
>that setting the variable causes side effects; for example, a trace
>might be used to notify a control whenever the value of a variable
>changes, so that the variable's value can be displayed continuously on
>the screen.
At this stage the argument gets to the utterly riduclous
stage. According to Ousterhout, because Scheme has only 5 "primitive"
operations which execute only a few instructions, therefore to do
anything in Scheme must be orders of magnitude more verbose than in
Tcl which has lots of primitive operations. NOT!
The convenience of performing complicated tasks is partly because of
the elegance of the language, but mostly has a lot to do with the
design of the libraries it has associated with it. Naturally Tcl can
do a lot of things with a few lines of code, because it is supported
by truckloads of library code doing the real work. But that is a
benefit of Tk. Not Tcl.
>Because of the features described above, scripting languages allow
>very rapid development for applications that are gluing in
>nature. Table 1 provides anecdotal support for this claim. It
>describes several applications that were implemented in a system
>programming language and then reimplemented in a scripting language,
>or vice versa.
This supposed comparison has a lot of flaws.
- It only makes comparison with C, C++ and Java. Hardly a wide enough
selection to draw the sweeping conclusions he then goes on to draw.
- comp.lang.tcl is hardly an unbiased source of information.
- It's not clear how much advantage was drawn from having the code
already implemented in the "systems" language
- There is no mention about whether the "systems" language
implementation used an extensive set of libraries such as that which
comes with Tcl, or whether they decided to reinvent every wheel
themselves, as so often happens on C and C++ projects.
- While the Java comparison makes a better one than C and C++, Java is
a far from mature technology with as yet poor library support.
In summary, the table is completely meaningless without further
information.
>The scripting versions typically required 5-10x less code or
>development time than the system programming versions. Applications
>that involved more complex algorithms or data structures, such as the
>last example in the table, benefit less from a scripting language than
>applications that are mostly gluing.
>
>To summarize, scripting languages are designed for gluing
>applications. They provide a higher level of programming than assembly
>or system programming languages, much weaker typing than system
>programming languages, and an interpreted development
>environment. Scripting languages trade off execution efficiency for
>speed of development. Figure 1 compares scripting languages with
>system programming languages graphically.
>
>4 Different tools for different tasks
>
>A scripting language is not a replacement for a system programming
>language or vice versa. Each is suited to a different set of
>tasks. For gluing and system integration, applications can be
>developed 5-10x faster with a scripting language; system programming
>languages will require large amounts of boilerplate and conversion
>code to connect the pieces, whereas this can be done directly with a
>scripting language. For complex algorithms and data structures, the
>strong typing of a system programming language makes programs easier
>to manage. Where execution speed is key, a system programming language
>can often run 10-20x faster than a scripting language: the flexibility
>provided by the scripting language results in more run-time checks.
>
>In deciding whether to use a scripting language or a system programming language for a particular task, consider the following questions:
>
> Is the application's main task to connect together pre-existing components?
> Will the application manipulate a variety of different kinds of things?
> Will the application's functions evolve rapidly over time?
> Does the application need to be extensible?
Pretty much all programming tasks have the above attributes. Go and
ask a programmer working on a project if...
- They will save time by using pre-existing components.
- The application has to do different things
- The application will change over time
- The application needs to be extensible.
Of course these statements are the definition of a normal evolving
software project.
>"Yes" answers to these questions suggest that a scripting language will work well for the application. On the other hand, "yes" answers to the following
>questions suggest that an application is better suited to a system programming language:
>
> Does the application implement complex algorithms or data structures?
> Does the application manipulate large datasets (e.g. all the pixels in an image) so that execution speed is critical?
> Are the application's functions well-defined and changing only slowly?
Here is the problem with scripting languages. Most applications start
off with a simple model and structure, a modest sized dataset, and a
well-defined problem. But then guess what? People want more features
leading to more complex algorithms and the need for data
structures. People start to feed larger and larger datasets into the
program. And the requirements of the program start to change and
change. Then you have to start all over from scratch because you find
that Tcl doesn't scale.
>Most of the major computing platforms over the last 30 years have
>provided both system programming and scripting languages. For example,
>one of the first scripting languages was JCL (Job Control Language),
>which was used to sequence job steps in OS/360. The individual job
>steps were written in PL/1, Fortran, or assembler language, which were
>the system programming languages of the day. In the Unix machines of
>the 1980's, C was used for system programming and shell programs such
>as sh and csh for scripting. In the PC world of the 1990's, C and C++
>are used for system programming and Visual Basic for scripting. In the
>Internet world that is taking shape now, Java is used for system
>programming and languages like JavaScript, Perl, and Tcl are used for
>scripting.
>
>Scripting and system programming are symbiotic. Used together, they
>produce programming environments of exceptional power: system
>programming languages are used to create exciting components which can
>then be assembled using scripting languages. For example, much of the
>attraction of Visual Basic is that system programmers can write VBX
>components in C and less sophisticated programmers can then use the
>components in Visual Basic applications. In Unix it is easy to write
>shell scripts that invoke applications written in C.
While Unix shell scripts are a big improvment on what existed
pre-Unix, they still have a lot of problems which could be better
solved using a different paradigm. For example, a lot of shell script
work involves parsing and re-parsing the text streams. One can imagine
a paradigm where objects instead of strings are passed around. Let's
imagine an "ls" directory lister which generates a collection of
directory entry objects. Each entry object has a print method which
prints the same as the Unix style "ls". Thus typing "ls" at the
keyboard does the same thing. And if there is some special reason why
you want to use the pure text version in a script you can do so. But
much more typically you want to use some of the fields in the "ls"
output to do calculations. "Which directory entries are older than
12/Feb/1997?" VERY difficult to do with Unix shell. Trivial in a scsh
or CLOS style language. One can imagine writing something like (map
(lambda (d) (< (file-time d) "12/Feb/1997")) (ls))
>One of the
>reasons for the popularity of Tcl is the ability to extend the
>language by writing C code that implements new commands.
>
>5 Scripting is on the rise
>
>Scripting languages have existed for a long time, but their importance
>has increased in recent years because the application mix has shifted
>more towards gluing applications. Three examples of this shift are
>graphical user interfaces, the Internet, and component frameworks.
>
>User interfaces are fundamentally gluing applications: the goal is not
>to create new functionality, but to make connections between a
>collection of graphical controls and the internal functions of the
>application. Scripting languages have always been the primary vehicle
>for creating user interfaces, whether the user interface was a card
>deck as in OS/360, a command line on a terminal as in Unix, or a
>graphical user interface as with Tcl or Visual Basic. With the arrival
>of graphical user interfaces (GUIs) in the 1980's the richness of user
>interfaces increased dramatically, as did the development effort
>required to create them. The GUI accounts for half or more of the
>total effort in many programming projects.
>
>I am not aware of any rapid-development environments for GUIs based on
>a system programming language.
Since Ousterhouts world view only includes "system" languages and
"scripting" languages, and his definitions of these excludes lots of
better and much more viable alternatives, his whole argument amounts
to a straw man.
>Whether the environment is Windows,
>Macintosh Toolbox, or Unix Motif, GUI toolkits based on languages like
>C for C++ have proven to be hard to learn, clumsy to use, and
>inflexible in the results they produce. Some of these tools have very
>nice graphical tools for designing screen layouts, but things become
>difficult as soon as the designer begins writing code to provide the
>behaviors for the interface elements. All of the best
>rapid-development GUI environments are based on scripting languages:
>Visual Basic on the PC, HyperCard on the Macintosh, and Tcl on
>Unix. Thus scripting languages have risen in popularity as the
>importance of GUIs has increased.
>
>The growth of the Internet has also popularized scripting
>languages. The Internet is a gluing environment. It doesn't create any
>new computations or data; it simply makes a huge number of existing
>things easily accessible. The ideal language for most Internet
>programming tasks will be one that makes it possible for all the
>connected components to work together, i.e. a scripting language. For
>example, Perl has become popular for writing CGI scripts and
>JavaScript is popular for scripting in Web pages.
>
>The third example of scripting-oriented applications is component
>frameworks. Although system programming languages work well for
>creating components, the task of assembling components into
>applications is better suited to scripting. Without a good scripting
>language to manipulate the components, much of the power of a
>component framework is lost. This may explain in part why component
>frameworks have been more successful on PCs (where Visual Basic
>provides a convenient scripting tool) than on other platforms such as
>Unix/CORBA where scripting is not included in the component framework.
>
>Another reason for the increasing popularity of scripting languages is
>the ever-increasing speed of computer hardware. It used to be that the
>only way to get acceptable performance in an application of any
>complexity was to use a system programming language. In some cases
>even system programming languages weren't efficient enough, so the
>applications had to be written in assembler. However, machines today
>are 100-500 times faster than the machines of 1980. Many applications
>can be implemented in an interpreted language and still have excellent
>performance (for example, a Tcl script can manipulate collections with
>hundreds or thousands of objects and still provide good interactive
>response). As computers get faster, fewer and fewer applications will
>need to be implemented in a system programming language to get
>adequate performance.
>
>One final reason for the increasing use of scripting languages is a
>change in the programmer community. Twenty years ago most programmers
>were sophisticated programmers working on substantial
>projects. Programmers in that day expected to spend several months to
>master a language and its programming environment, and system
>programming languages were designed for such programmers. However,
>since the arrival of the personal computer, more and more casual
>programmers have joined the programmer community. For these people,
>programming is not their main job function; it is a tool that they use
>occasionally to help with their main job. Examples of casual
>programming are writing macros for a spreadsheet or writing a simple
>database query. Casual programmers are not willing to spend months
>learning a system programming language, but they can often learn
>enough about a scripting language in a few hours to write useful
>programs. Scripting languages are easier to learn because they have
>simpler syntax than system programming languages and because they omit
>complex features like objects and threads.
Oh really?? Scripting languages are simpler and easier to learn than
systems languages? That is a very broad claim to make. It is also a
lot of rot. Take perl for example. A difficult language to truely
understand and master. Each language has it's own unique
characteristics and difficulties. It has nothing to do with whether it
is a supposedly "systems" or "scripting" language.
>For example, compare Visual
>Basic with Visual C++; few casual programmers would attempt to use
>Visual C++, but many have been able to build useful applications with
>Visual Basic.
Yeah right. Use C++ as a comparison against BASIC. Why not compare
Perl to Scheme? Who wins then?
>Even today the number of applications written in scripting languages
>is much greater than the number of applications written in system
>programming languages. On Unix systems there are many more shell
>scripts than C programs, and under Windows there are many more Visual
>Basic programmers and applications than C or C++. Of course, most of
>the largest and most widely used applications are written in system
>programming languages, so a comparison based on total lines of code or
>number of installed copies may still favor system programming
>languages. Nonetheless, scripting languages are already a major force
>in application development and their market share will increase in the
>future.
>
>6 The failure of object-oriented programming
>
>Scripting languages have received little attention in the programming
>language community or in the press; instead, most of the attention has
>been focused on object-oriented programming languages such as C++ and
>Java. Object-oriented programming is widely believed to represent the
>next major step in the evolution of programming
>languages. Object-oriented features such as strong typing and
>inheritance are often claimed to reduce development time, increase
>software reuse, and solve many other problems including those
>addressed by scripting languages.
>
>Unfortunately, there is not much evidence that object-oriented
>programming produces the benefits claimed for it. Some projects have
>claimed success with object-oriented languages, but others have
>reported that languages like C++ actually made software management
>problems worse.
So object oriented technology is condemned because of the failure of
C++? Yeah right.
>I do not know of any studies showing substantial
>reductions in development costs due to object-oriented programming,
>and some language experts are now beginning to speak out against
>object-oriented programming [3].
>
>The reason why object-oriented programming has not lived up to
>expectations is that it doesn't raise the level of programming or
>encourage reuse. Programmers still work with small basic units that
>must be described and manipulated in great detail. In principle,
>powerful library packages could be developed, and if these libraries
>were used extensively it could effectively raise the level of
>programming. However, not many such libraries have come into
>existence.
Oh really?
>The strong typing of object-oriented languages encourages
>narrowly defined packages that are hard to reuse. Each package
>requires objects of a specific type; if two packages are to work
>together, conversion code must be written to translate between the
>types required by the packages.
Again this argument about "conversion code". Hard to argue with since
he gives no examples. A vague argument is an unassailable argument.
>Another problem with object-oriented languages is their emphasis on
>inheritance. Implementation inheritance, where one class inherits part
>of its implementation from another, is simply a bad idea. It binds the
>implementations of classes together so that neither can be understood
>without the other: the subclass cannot be understood without knowing
>how the inherited methods are implemented in the superclass, and the
>superclass cannot be understood without knowing how its methods are
>inherited in subclasses. In a complex class hierarchy, no individual
>class can be understood without understanding all the other classes in
>the hierarchy. Even worse, a class cannot be separated from its
>hierarchy for reuse. Multiple inheritance only makes these problems
>worse. Implementation inheritance causes the same intertwining and
>brittleness that have been observed when goto statements are
>overused. As a result, object-oriented systems suffer from complexity
>and lack of reuse.
Here we have proof that Ousterhout has totally lost the plot with this
paper. It's hard to know where to start in critisizing such a brazen
set of lies and foolish claims.
The simplest way of pulling all this stupidity to the ground seems to
be to point Ousterhout to his own work in Tcl/Tk.
I would describe the essence of object oriented programing as 2
things...
- Polymorphism and/or interface inheritance... The ability for
different types of objects to react to the same message in different
but appropriate ways.
- Implementation inheritance... The ability to re-use part of an
already existing class'es implementation to make newer and more
complex and more specific classes.
NOW LOOK AT TK!!!! It's object oriented!!!!!!! It's based on all the
principles that Ousterhout is deriding. I must say this makes him look
like a fool.
>Scripting languages, on the other hand, have actually generated
>significant software reuse. They use a model where interesting
>components are built in a system programming language and then glued
>together into applications using the scripting language. This division
>of labor provides a natural framework for reusability. Components are
>designed to be reusable, and there are well-defined interfaces between
>components and scripts that make it easy to use components.
Apparently "well-defined interfaces" and the assembling of
"interesting components" are the sole domain of untyped scripting
languages. Amazing.
>For
>example, in Tcl the components are custom commands implemented in C;
>they look just like the builtin commands so they are easy to invoke in
>Tcl scripts. In Visual Basic the components are VBX or ActiveX
>extensions, which can be used by dragging them from a palette onto a
>form.
>
>7 What will happen to system programming languages?
>
>It might seem from the above arguments that scripting languages will
>eventually replace system programming languages entirely. After all, a
>similar effect occurred with assembly language. In the early 1960's,
>most serious programming was done in assembly; higher level languages
>like Fortran and Algol were widely viewed as too slow for serious
>programming tasks. But the quality of compiled code improved and
>machines got faster, so the performance differences were less
>important. At the same time, it became clear that programmers were
>substantially more productive with high level languages than with
>assembly. Over time, more and more people decided that it was worth
>giving up a little speed to get faster application development. Today,
>assembly language is rarely used, even for the most
>performance-critical code. The same arguments might be made for
>scripting versus system programming: scripting does not use the
>computer as efficiently as system programming, but it enables much
>faster development.
Spare me!! A world where Tcl rules, and data structures are the sole
realm of specialized "systems programmers".
>However, I doubt that system programming languages will disappear to
>the same extent that assembly languages have. Scripting languages are
>not designed to serve all purposes. They work particularly well for
>gluing together components, but they are not as suitable for creating
>the components. The strong typing of system programming languages
>makes it easier to build complex data structures and algorithms; for
>example, trees and other pointer-rich structures are easier to
>implement in a system programming language than a scripting
>language. A scripting language is great for writing a database query,
>but if you're writing a database engine you're better off with a
>system programming language.
>
>Thus system programming languages will continue to play an important
>role in computers, but they will be used primarily for creating
>components and fixed-function applications such as database
>servers. Many of the more glue-like areas where system programming
>languages are used today, such as GUIs and enterprise applications,
>will come to be dominated by scripting languages.
>
>8 Conclusion
>
>Scripting languages represent a different set of tradeoffs from system
>programming languages. Scripting languages give up execution speed and
>strength of typing relative to system programming languages but
>provide significantly higher programmer productivity and software
>reuse. This tradeoff makes more and more sense as computers become
>faster and cheaper in comparison to programmers. System programming
>languages are well suited to building complex data structures and
>algorithms from scratch, while scripting languages are well suited for
>gluing applications such as graphical user interfaces and component
>assembly. Gluing tasks are becoming more and more prevalent, so
>scripting will become an even more important programming paradigm in
>the next century than it is today.
------------------------------
Date: 2 Apr 1997 05:12:18 GMT
From: tjreedy@udel.edu (Terry Reedy)
Subject: Re: Unix and ease of use (WAS: Who makes more ...)
Message-Id: <5hspri$grh$1@news.udel.edu>
In article <33414A13.4D45@absyss.fr>, seay@absyss.fr says...
> But remember that
>everytime someone does some form of freeware (GNU,
>Perl, Linux, whatever), this is a bit of socialism.
NO! freeware is voluntary activity (free enterprise) with no guns or
g-men in sight. It is the opposite of socialism.
------------------------------
Date: Tue, 01 Apr 1997 22:47:46 -0800
From: albert_b@pacbell.net
Subject: Re: Using Perl with MS-Access
Message-Id: <33420112.4D0B@pacbell.net>
Kevin Posen wrote:
>
> Hi.
>
> I've been requested to use a Perl CGI script to receive data from an HTML form
> and to add this to a database maintained in MS-Access.
>
> I have no idea where to start as I haven't used Access (or any other database
> maintenance system) much at all.
>
> Any ideas?
>
> Thanks,
> Kevin Posen
you might try just writing the data into CSV (or other delimited) text
files and then writing a macro in Access to read the data in. I believe
it's actually possible to start an Access session up, and have it run an
"autoexec" macro (or something similar) which reads the data from the
text file into a table. anyway, that's one approach....
-- Albert_Braun@adventure.com
------------------------------
Date: Wed, 02 Apr 1997 00:41:09 -0600
From: Brendon Oliver <brendon@conibm.aldis.com.au>
To: mike_hayden@inetuk.wang.com
Subject: Re: Where do I get 'h2n' perl script for unix
Message-Id: <859962845.24876@dejanews.com>
In article <01bc3e84$52b48a20$330873c1@mikeh_lt.inetuk.wang.com>,
"michael" <mike_hayden@inetuk.wang.com> wrote:
>
> Dear All,
>
> I'm trying to locate the 'h2n' hosts-to-name perl tool for use in
> publishing DNS files on a Unix system.
>
> I've got Perl5 but this doesn't include the above script. I've looked on
> various sites, namely www.perl.hip.com and www.ora.com but without luck. I
> realise I could make use of the NT version of perl+scripts as this already
> has the 'h2n' script, but this requires me running NT Workstation and then
> transmitting the files generated onto the unix end system.
>
> It would be neater and more compact to keep averyting together under one
> OS.
>
> Anyone know any good perl-script library sites for unix??
>
> thankyou very much for your help.
>
> Michael Hayden
Try the "DNS Resources Directory" at http://www.is.co.za/dnsrd/ under
the 'Tools' section.
HTH.
- Brendon
brendon@conibm.aldis.com.au
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 218
*************************************
