In article <5ja4a2$o1u@roar.cs.utexas.edu> wilson@cs.utexas.edu (Paul Wilson)
writes:
This is understandable. How to you feel about scripting languages
that have a more C-like syntax, so that you'd write
func(arg1, arg2)
except when emitting a command to the operating system?
It depends on the project. In the current case, I use my Tcl-based
language to write tools, but also to exercise APIs interactively. I
prefer to type
func arg1 arg2
when working interactively. When writing tools, the
func(arg1, arg2)
notation is nice, but I'd rather use the same in both places.
Disregarding the parenthesis issue and the infix vs. prefix issue
(which can be solved with a simple parser on top of something like
Scheme), how do you feal about the $x substitution thing?
The $x substitution thing took some getting used to, but I encountered
both shells and perl first, so it wasn't too add. I find that the
ability to build up complex strings quickly using substitution is
really handy for quick-and-dirty tool development. You can do much
the same thing in Lisp or Scheme, of course, using lists instead of
strings...but I can pass a string to native function written in C
and let it parse the string any way it likes.
So, I like $x for the most part.
>I did a web search yesterday, and found a couple of Scheme
>implementations which would probably work as well for my purposes as
>Tcl, except for the psychological issues I mention. If I were
>starting over, though, I'd still pick Tcl.
Is this because you like programming in a shell style (e.g., don't
mind having to force evaluation by controlling substitution) or
because Scheme syntax is unfamiliar in other ways?
Mostly because all of the parentheses get to me, and because I think
I can more easily teach the rudiments of Tcl to people who want to use
my tools.
>It's plenty good enough,
>and it "feels" better to me. Frankly, that's what's important.
That's understandable, too. What I'm trying to figure out is which issues
are the most important in overcoming resistance to things like Scheme
and Smalltalk.
Ahhh. Smalltalk. That's really another discussion, but here's why
I don't like Smalltalk. I don't think of Smalltalk as competing with
Tcl, by the way, but then, I'm not one of the people who develops
large applications entirely in Tcl.
1. I like traditional expressions and control structures.
A C programmer can get the gist of a Fortran, BASIC, Pascal,
Ada, or Java program without too much effort. The syntax isn't
identical, but the basic model is much the same.
2. (And this is the kicker) I really dislike having my application
and the Smalltalk library classes live in the same "space". In the
Smalltalk system I've looked at (Smalltalk V), if I wanted to
develop two separate applications they either needed to live in the
same class tree, or I needed to maintain too entirely separate
"images", which included all of the system classes. This gives me
chills, for some reason.
As someone on this thread has commented, OOP in Java is more like OOP
in Smalltalk than it is OOP in C++, and I think this is true...but in
Java, there's a nice clean separation between my code and anybody
else's code. I like that. Again, this may be a purely psychological
issue, but then, I program better when I'm happy. :-)
Will
--
--------------------------------------------------------------------------
Will Duquette, JPL | William.H.Duquette@jpl.nasa.gov
But I speak only | will@bean.jpl.nasa.gov
for myself. | It's amazing what you can do with the right tools.
|