Additional Information For Scripting White Paper
John K. Ousterhout
This page contains additional data related to the white paper "Scripting:
Higher Level Programming for the 21st Century". It includes the following
information:
The button example can't be implemented in Java without providing additional
boilerplate code required for the basic applet. To level the playing
field relative to Tcl, a simple applet containing a single button was
written, then the code was modified to add a second button. Only the
7 additional lines required for the second button were counted in the
comparison against Tcl. These 7 lines are marked with +s. This code
was contributed by Stephen Uhler.
// Hello button using awt (jdk 1.0 compatible)
import java.awt.*;
public class hello extends java.applet.Applet {
+ public Button hello;
public Button bye;
public void init() {
+ hello = new Button();
+ hello.setFont(new Font("Times", Font.PLAIN, 16));
+ hello.setLabel("hello");
+ this.add(hello);
bye = new Button();
bye.setFont(new Font("Times", Font.PLAIN, 16));
bye.setLabel("bye");
this.add(bye);
}
public boolean handleEvent(Event event) {
if (event.target == bye && event.id == event.ACTION_EVENT) {
System.exit(1);
+ else if (event.target == hello && event.id == event.ACTION_EVENT) {
+ System.out.println("hello");
} else {
return super.handleEvent(event);
}
return true;
}
public static void main(String[] args) {
Frame f = new Frame("hello Test");
hello win = new hello();
win.init();
f.add("Center", win);
f.pack();
f.show();
}
}
The implementation of the button example in C++ with Microsoft Foundation
Classes also requires quite a bit of boilerplate code that isn't attributable
to any particular widget. In this code, contributed by Colin Stevens,
only the lines that are actually required for the particular button
widget are counted. These are marked with +s. The code to position
the button window in its parent is not counted, since the corresponding
code (1 additional line) was not included in the Tcl example.
// buttonDlg.cpp : implementation file
//
#include "stdafx.h"
#include "button3.h"
#include "buttonDlg.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
+ #define IDC_INIGO 100
/////////////////////////////////////////////////////////////////////////////
// CButtonDlg dialog
CButtonDlg::CButtonDlg(CWnd* pParent /*=NULL*/)
: CDialog(CButtonDlg::IDD, pParent)
{
+ m_pFont = NULL;
+ m_pButton = NULL;
//{{AFX_DATA_INIT(CButtonDlg)
//}}AFX_DATA_INIT
}
BEGIN_MESSAGE_MAP(CButtonDlg, CDialog)
//{{AFX_MSG_MAP(CButtonDlg)
+ ON_BN_CLICKED(IDC_INIGO, OnInigo)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CButtonDlg message handlers
/*
* button .b -text "My name is Inigo Montoya" -font "times 12" \
* -command {tk_messageBox -message "hello"}
*/
BOOL CButtonDlg::OnInitDialog()
{
/*
* Create button widget.
*/
+ CButton *buttonPtr = new CButton();
+ char *text = "My name is Inigo Montoya";
/*
* Create "times 12" font.
*/
+ CFont *fontPtr = new CFont;
+ fontPtr->CreateFont(16, 0, 0, 0, 700, 0, 0, 0, ANSI_CHARSET,
+ OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
+ DEFAULT_PITCH|FF_DONTCARE, "Times New Roman");
/*
* Measure the text to be displayed so we can request the
* appropriate sized button. The padding used below are
* the same ones as the defaults for buttons under Tk.
*/
+ CDC *dcPtr = GetDC();
+ fontPtr = dcPtr->SelectObject(fontPtr);
+ CSize size = dcPtr->GetTextExtent(text, strlen(text));
+ fontPtr = dcPtr->SelectObject(fontPtr);
+ ReleaseDC(dcPtr);
+ size.cx += 9;
+ size.cy += 9;
/*
* Create button window with specified text and size.
* Set the font before displaying the window.
*/
+ buttonPtr->Create(text, WS_CHILD | WS_TABSTOP,
+ CRect(0, 0, size.cx, size.cy), this, IDC_INIGO);
+ buttonPtr->SetFont(fontPtr);
/*
* To place button at a specified position without changing
* its requexted size, do the following:
*/
buttonPtr->SetWindowPos(NULL, 20, 30, 0, 0,
SWP_NOSIZE | SWP_NOZORDER | SWP_SHOWWINDOW);
/*
* Remember the CButton and HFONT we created so that when the
* main window is destroyed, we can release the resources and
* free the memory we allocated (when the button HWND is destroyed,
* MFC will NOT automatically delete the wrapping CButton widget or
* free the HFONT it's using).
*/
+ m_pButton = buttonPtr;
+ m_pFont = fontPtr;
return TRUE;
}
void CButtonDlg::PostNcDestroy()
{
+ delete m_pFont;
+ delete m_pButton;
CDialog::PostNcDestroy();
}
+ void CButtonDlg::OnInigo()
+ {
+ MessageBox("hello", "", MB_OK | MB_ICONINFORMATION);
+ }
Table 1 of the white paper summarizes several applications that were
implemented twice, once in a system programming language and once in
a scripting language. I gathered the data for this table by posting
an article on the comp.lang.tcl newsgroup asking for people who had
implemented applications twice to share their experiences. Several
people responded, and the email they sent me provided the raw data
for the table. I used all of the responses that were complete enough
to provide a quantitative comparison of either development time or
lines of code. The raw email messages are reproduced below (I have
removed identifying information for the sender in one case where the
sender asked to remain anonymous).
Database library and application (Ken Corey)
Date: Mon, 17 Feb 1997 12:22:03 -0800
From: Ken Corey
To: John Ousterhout
Subject: Re: Tcl vs. C/C++/Java: quantitative data?
John Ousterhout wrote:
> I'm writing a white paper on the difference between scripting (e.g. in Tcl)
> and system programming (e.g. in C, C++, or Java), and one of the claims I
> want to make is that you can often develop applications 10x or more faster
> in a scripting language. I'd like to back up this claim with some
> quantitative data, but unfortunately I don't have much except vague
> recollections of things people have said to me in the past.
When a job position came open at Sun to work on Tcl, I jumped at the
chance, because of the experience I'd had while working at my previous
job.
A guy there had written a C++ based Database library application.
Basically, it was a very complex library allowing access to a table, and
providing minimal SQL query-by-example with ad-hoc queries. It was cool,
because it allowed managers interesting new ways to look at their data
that they didn't know even existed.
I was asked to write an application using this library. This took ~8
weeks for me to learn what he'd done in his C++ library, and write the
application I was supposed to write. (2 months!) Of course, the guy
who wrote this library said it was quite easy to use, and everyone was
convinced. It took me 2 months to write an application against it, with
the guy there to help. That was one application!
I found Tcl/Tk, played with it, and found the SybTcl database. I
realized that I could do the same library in *much* shorter time. Once
I got permission, I wrote it in 1 week, and it had more capabilities
then the C++ library. You could write new "applications" that were
basically configuration scripts that sourced the workhorse library.
These were *real* time savers. If you knew what you were doing, you
could write the configuration script in about 2 hours. If you didn't
know what you were doing, it took 1 day. If you had no clue about
computers, it took about 3 days.
*Many* of these applications appeared over the next few months...which
*was cool, because I ended up getting a bonus out of it...*grin*
Computer system test and installation (Andy Belsey)
Date: Thu, 20 Feb 97 09:11:55 MET
From: "Andy Belsey, Engineering Services, Ayr 20-Feb-1997 0814 +0000"
To: ouster@tcl.eng.sun.com
Subject: Scripting vs. C/C++
Hi John,
I saw your post about comparisons of scripting languages vs. C/C++. I'm
a software engineer working in the European Manufacturing plant of Digital and
have just put a system test and FIS (Factory Installed Software) application
into production that replaced two applications written in C. I started this
from scratch last June and the first Production systems were shipped yesterday
using the new software (although we are still in pilot version mode).
Maybe the comparison will not be what you're after here as the C apps were
developed over a number of years by different teams and I was the only one
working on the scripted version. However, a few statistics for you:
There were two C apps: one for test delivery and one for FIS delivery. The
latter was developed because of the shortcomings of the former. The test one
had about 10 man years of effort in it (it had its own language, compiler and
virtual processor). The FIS one had about 5 man years in it.
The replacement that I came up with uses Expect, tcl, tk & Perl and took me
about 8 months to bring to a Production-usable state from scratch. I have
become a huge fan of scripting languages - Expect was ideal for our problem
space (interacting with remote ASCII consoles of the target systems). The fact
that Expect was layered on an extremely useful langauge (tcl) was also very
significant in developing the new app so quickly and with so little resource.
You are welcome to more details if you want. Thank you for tcl (and Don Libes
for Expect). You have saved us a huge amount of time and effort.
/andy
--------------------------------------
Andy Belsey, System & Network Manager,
Digital Equipment, Scotland.
Date: Tue, 11 Mar 97 08:25:54 MET
From: "Andy Belsey, Engineering Services, Ayr"
To: ouster@tcl.eng.sun.com
Subject: Re: Scripting vs. C/C++
>I have a followup question on an email message you sent to me a
>few weeks ago, comparing development times in C vs. Tcl:
>Did the replacement that you built replace both of the applications or
>just one? If just one, which one? By any chance do you know how many
>lines of source code there were in the C and Tcl applications?
>Thanks for the additional information.
Yes, the Tcl/Expect code combines (and replaces) both the C applications. The
FIS application was written because of severe limitations in the Test app but a
lot of the functionality of both apps is the same (but coded differently :-)).
I worked on both C coding teams (at different times), so I still have access
to the source code. Running all the source files through a wc -l produces:
Test C application: 272,310 lines of code
FIS C application: 89,567 lines of code
Both the above figures include all the C and include files with comments. The
Tcl/Expect version has (including comments):
Tcl/Expect code: 5,693 lines
Perl code: 2,008 lines
Hard to believe when I see these figures but wc -l doesn't lie. The test app
is so bloated because it has its own language compiler and virtual processor
whereas the FIS app just uses hard-coded logic.
You must get tired of people telling you how great tcl is but my experience
with both tcl and perl has been nothing short of hugely successful (both for me
as a programmer and my engineering group as a business within Digital). There
is no way that I could have designed, engineered and put into Production a
joint app as quickly by using any other language (this from a die-hard C/C++
programmer).
Hope that helps - feel free to ask anything else you may need. I'd be
interested in seeing a copy of your paper when you're finished (assuming you
will publish it for general viewing).
/andy
--------------------------------------
Andy Belsey, System & Network Manager,
Digital Equipment, Scotland.
Security scanner (Jim Graham)
From: Jim Graham
Subject: Re: TCL/Tk 8.0 Release?
To: ouster@tcl.Eng.Sun.COM
Date: Tue, 22 Apr 1997 07:57:57 -0600 (CDT)
...
Btw, here's another example....
I have a security scanner program (written in C, with some help from
YACC) that watches over my systems in pseudo-real-time. It sits in
the background, quietly watching every log file (including a bunch of
non-standard ones), and takes action when needed. Normally, it logs
events to a file, which is then monitored by another program (they used
to be the same program, but for various reasons, it made sense to split
them up). The old monitor program was written in C with curses, and took
me a good bit of time to get to a point where I really liked it. It's a
large (to me) program, at about 3000-4000 lines of C code.
I re-wrote the whole monitor program, which now runs as an X application
with *MORE* power than it had before, in about 300 lines of Tcl/Tk code.
Oh, btw, the majority of its functionality took one afternoon to write. :-)
Thanks,
--jim
Display oil well production curves (Dan Schenck)
Date: Tue, 18 Feb 1997 20:57:47 -0600
From: Dan Schenck
To: ouster@tcl.Eng.Sun.COM
Subject: re: Tcl vs. C/C++/Java: quantitative data?
John,
A little over 3 years ago I wrote an application in Tcl/Tk that
interfaced, through X Events message passing, to a large
C/X-Windows-based system that we maintained. The Tcl application was
written as a proof of concept, and was designed to display the
production decline curves for a producing oil or gas well.
It took me approximately 2 weeks effort to complete the program. To
build the required graphs, I used the BLT extension. I also wrote an
extension to Tcl to capture the X Events produced by the primary system
and a command to compute the forecast decline curves. The X Events were
used to drive my application. In addition, the application extracted
data from a Sybase database using the sybtcl extension.
After seeing the Tcl application, our clients decided we should proceed
with a C implementation of the project. Using an X-Windows GUI builder
tool and C, another developer rewrote my application for integration
into the main system. It took him 3 months work to duplicate the work I
had done in Tcl/Tk. That is a 6:1 difference.
The C application had no essential difference in functioality (it ran
slightly faster), so I believe that this is a fair comparison of
head-to-head development time.
I believe that I could do the work today much quicker, since my original
work involved learning Tcl/Tk, learning how to use some sophisticated
Tcl extensions and discovering how to build Tcl extensions.
This is the only situation that I have a direct comparison for of
independent development of the same application in both Tcl and C.
However, it is my gut feel that a 10:1 performance improvement over C
programming isn't far off base for an experienced Tcl/Tk developer.
I'm anxious to see a summary of the responses you get to this question.
Dan Schenck
POSC
Houston, TX
Query dispatcher ( Paul Healy)
To: ouster@tcl.Eng.Sun.COM
Subject: Re: Tcl vs. C/C++/Java: quantitative data?
Date: Tue, 25 Feb 1997 23:08:33 +0000
From: Paul Healy EI9GL
In the middle of 1996 I implemented a small `dispatcher' application
in tcl. The application is designed to sit between heavy-weight
processes (typically RDBMS server processes that undertake SQL
queries), and transient client processes (typically cgi programs).
The RDBMS process would start up (typically taking about 30 sec
to setup a channel to the database), and then hang around
persistantly for long periods answering queries.
The original version of this had been written in a C using threads
and an XTI streams communication layer. I wasn't around when this
version was written, so I can't say how long it took to design/
write and debug. However by the time I arrived in the company
nobody could follow what was going on inside it (including the
person who wrote it!). I guess that it took on the order of one to two
man months to do all this. The C code (just .c files) ran to 1200
lines (no comments).
I wrote a version in tcl in just under a week (using sockets and
fileevents, 20 procs, average number of lines/proc about 15) taking
500 lines (lots of comments, and a reasonably generic loggin facility
to debug it).
I added a snazzy Tk user interface to monitor and control the application
in another 300 lines (the original had a port you could telnet to and ask
it very rudimentary things). The user interface was designed
to be non-intrusive on program (it just associated widgets -textvariables
with interesting variables), and worked out so well, that something
that had originally begun as a programming exercise (I wanted to
figure out how to program sockets in tcl) replaced the existing
tried and tested (C) implementation.
This is a lot longer than your requested 2-3 lines, but I hope that
it will useful to you.
Good luck with the expansion of the tcl unit at Sun. If you ever
decide to do something with CORBA and tcl, I will come looking a
job...
Paul
Spreadsheet tool
Date: Sat, 22 Feb 1997 20:08:40 CST
To: ouster@tcl.Eng.Sun.COM
Subject: Tcl vs. C
John,
I couldn't resist replying to your query on the efficiency of TCL vs. C
coding since I just finished an exercise of just that sort. I have been
working on a spreadsheet program (don't ask why) that have the basic features
of typical GUI programs, and have a file that stores and manipulates the
the properties of a cell. The TCL version is 379 lines; the C version
(written to get better speed) is 1460 lines. So that is close to a factor
4. There is nothing particularly extraordinary about what the code does
so this result may scale well to other situations. As for speed of coding
time, I think you would need to conduct controlled experiments to get a
quantitative number. However, the adage that it takes the same length
of time to code a line regarless of language is probably not true for TCL
vs C: I am sure that TCL is faster to code (per line) because of the ability
to bypass the compile/link step, and also because if one is testing code
that requires some initialization steps to set up a particular state,
much of that state can be maintained while iteratively debugging TCL
(run-time sourcing of code), while C coding requires that you reinitialize
the state for each cycle of recompilation. Overall, I think the factor 10
is not unreasonable.
Simulator and GUI (Randy Wang)
Date: Fri, 24 Jan 1997 19:56:06 -0800 (PST)
From: Randolph Wang
To: ouster@tcl.Eng.Sun.COM
Subject: Re: Tcl/Java code sizes
tcl version: 1600 lines
java version: 3400 lines
1) functionalities:
a) the tcl version does a little more. very hard to put a number
on it, but if you make me, i'd say somewhere between 10-20%.
b) there was a conscious effort to make the java code reusable, so
1200 lines of the java code made into my personal library and
were more generic and bigger than they need be otherwise.
c) if the code size difference surprised you, it might help if i
told you the codes were not completely GUI -- there were
substantial chunks devoted to, for example, xFS coherence
algorithms. if you write a loop to cycle through all the
machines in a hash table, for example, you can imagine the
loop bodies would look very similar.
2) times:
a more useful metric for programming ease than code size is the
amount of time it took to write the programs.
a) the first 900 lines of the tcl version were written in a single
night (to meet a demo rehearsal deadline). the whole thing was
complete in less than a week.
b) the java version took a month. a drastic interface change from
the alpha version to JDK beta and bugs in AWT probably should
be blamed for at least a week of wasted time.
Randy