From: Bill Eldridge
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <33428EB7.3F4F@rfa.org>
> >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.
This is pretty doubtful - you can write and debug the same amount
of assembler & Python code in a year, including debugging? How
about developing new related programs based on earlier work?
How about modifying/debugging someone else's code? And completely
unrelated to the task you're trying to do? (device drivers,
numerical methods, GUI's, databases, etc.)
> >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.
Occasionally, "weakly-typed" languages are actually "programmer-typed":
"Oh, it screwed up an interpreted this as an integer, well, I'll just
throw an ascii conversion function around it".
Actually, I thought C++ allows pretty generic function mapping on
whatever types you throw into a function.
> > Scripting languages are often used to extend the features
> >of components but they are rarely used for complex algorithms and data
> >structures;
I thought Perl was quite good at complex data structures.
Maybe I'm confusing something (perhaps Perl really does nothing,
it's all just Unix/C at heart. Alas, we were fooled all along).
> >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);
CButton* button1;
CButton* button2;
button1 = new CButton();
button1->Create("Push me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
101)
button2 = new CButton();
button2->Create("Pull you", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
102)
font = new CFont;
font->CreateFont(16,0,0,0,700,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE,"times");
button1->SetFont(font)
button2->SetFont(font)
Basically 3 lines to create a font (reusable assuming you only
what a few types of fonts, set up a function to handle size changes
if it's the same, you can also create a simple function to handle
defaults for everything but the size and type.
3 lines to create a Button.
I don't know where Oesterhout's reference on MFC comes from
(I'm just looking at Brain & Lovette's book).
>
> >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.
> >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.
If you define the interface well in OOL's, you can handle a variety
of typed inputs. It's much easier to extend that typing in OOL's than
with something like C (and have deterministic output). I would guess
serious programmers do develop their own libraries, or work with
corporate standard ones (what does Adobe use? they can't be rewriting
every graphics routine from scratch). Having classes inherit methods
and types is much nicer than having everything default to a string
and thinking that's sufficient. MFC is a help for OOP exactly by
defining libraries that simplify programming. The dangers on
simplification
include that it might come at the expense of too much speed, that
it might not provide the tools to do everything a lower level
approach would, or that in doing more complex tasks, the "simpler"
language actually becomes more obfuscated than the lower-level
languages.
From: Erik Naggum
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Date:
Message-ID: <3068991370338285@naggum.no>
* Bill Eldridge
| I don't know where Oesterhout's reference on MFC comes from
| (I'm just looking at Brain & Lovette's book).
considering that bad code can be written in any language, any language
comparison performed using examples must be judged by the quality of the
examples in each language. it can't be all that hard to write a bad
example in language A and a good example in language B, and then proclaim
language B to be the winner -- this is how people compare languages all the
time, so either those who read them are bad programmers in any language (or
are not programmers at all) and don't know how to reject the bad examples,
or they already agree with the author of the comparison that language B is
better than language A. in either case, it's a waste of anything but
marketing money. it appears to me that this is indeed how Tcl is marketed.
in other words, prepare to see Tcl claim a significant market share. also,
I'm sure people who read a paper with such a pompous title are unable to
detect any amount of false marketing. "Scripting: Higher-Level Programming
for the 21st Century", indeed.
a language is only as good as the worst example in languages it claims to
win over.
#\Erik
--
I'm no longer young enough to know everything.