John Ousterhout <ouster@tcl.eng.sun.com> wrote in article
<5i7euq$cmg@engnews2.Eng.Sun.COM>...
>
[snip]
>
> 1. The paper is not intended to be a complete taxonomy of all programming
> languages nor is it intended to discuss every factor that contributes
> to the usefulness of a language.
Yet, you make some pretty sweeping characterizations about the _general_
adviseability of language features. Certainly, your comments regarding OOP
and implementation inheritance are not qualified with "as regards scripting
only" disclaimers.
> The paper has a very narrow focus,
> namely to explain what scripting is and why it's important. I
> intentionally limited the discussion to a few issues such as system
> programming vs. scripting, components vs. glue, and strongly typed
> vs. untyped. Of course there are other issues in programming language
> design. At the same time, I think that the issues in the paper
explain
> a lot about what's going on in real-world programming.
>
FWIW, I really like dynamic typing in an application language. In this we
agree in spirit, but I'm not so sure about the particulars. I like being
able to declare a variable of a specific type when I feel it's appropriate
-- something I do in VB a lot. OTOH, particularly in database apps and
other multi-lingual work, a strict type system can be a real pain.
>
> 3. It's very hard to settle arguments about programming languages
> because it's hard to produce meaningful quantitative evidence about
> things like programmer productivity. I tried to illustrate my points
> with historical examples and a few quantitative anecdotes, but I
> admit that these are soft.
>
Yes, it's a hard issue with soft evidence. However, from my own experience,
I know that using a high-level applications language, like PowerBuilder or
Visual Foxpro, can be far more productive in terms of LOC than using VB.
This is precisely because PB and VFP support inheritance. OTOH, the market
acceptance of VB forces me into using it, even though it inevitably leads
to trading off encapsulation and having massive duplication of glue-code,
which must be replicated in every form's events in order to have any reuse
at all. So, despite the fact that there may be counter-examples, all I can
say is that inheritance at the GUI component and form level can be a really
big win in the "real world".
>
> The white paper argues that you can't have a jack-of-all-trades
> language. Either you have a strongly typed language, which gives high
> speed and manageability but makes gluing hard, or you have a weakly
> typed language with the opposite properties.
>
There will always be trade-offs, but speed and easy integration with other
applications and languages do not have to be among them. For example, our
internal Lisp dialect has a VM architecture, yet generally outperforms
native-compiled VB5 code (no big shakes, but it's true). At the same time,
it integrates easily with VB and other OLE-supporting tools. It also
includes an easy interface to C functions. We're also adding native code
generation for WinTel, at which point we expect to be nipping the heels of
ANSI C in terms of speed. In our case at least, Lisp has proved to be a
pretty good scripting language, as well as a language suitable for creating
high-performance database applications.
Bill House
--
bhouse@dazsi.com
http://www.dazsi.com
|