On Dec 2, 8:21 pm, Vesa Karvonen <vesa.karvo...@[EMAIL PROTECTED]
> wrote:
> I think that the approach I'm using for test specification is more
> expressive (users can write their own shorthands) and less fragile and
> ad hoc (not dependent on an ad hoc naming convention) than the use of
> introspection to grep for functions matching a particular kind of name
Let me concede you this point,
I don't feel strongly about the test runner example.
> In my experience, introspection (and stuff like aspect oriented
> programming) tends to lead to fragile, non composable, hard to
> understand and debug, ad hoc hacks.
There are two usages for introspection: the "passive" usage, in which
you use introspection just for
do***entation/re****ting/debugging purposes,
and the "active" sense, in which you use introspection to operate on
you code,in the AOP sense. I think the "passive" usage is good in all
cir***stances, and so useful that I am willing to pay a small
performance penalty for it.
OTOH, the "active" usage can often be abused, leading, as you say, to
"fragile, non composable, hard to understand and debug, ad hoc hacks".
I actually even wrote a paper about metaclass abuse in Python
http://www.phyast.pitt.edu/~micheles/python/classinitializer.html
and I tend to avoid these tricks in production code. Nevertheless,
they
have their usages *a debugging and testing tools*.
For instance, just last week at work I was testing our logging
framework.
We essentially have a class with many methods doing many things, and
a runner methods that calls the other methods by adding logging
capabilities
(each method has its own logger instance). Since I wanted to test the
framework
and not the methods, I just wrote 5-6 lines of code to replace (at
runtime)
all methods with dummy methods, and I was done. In particular, I did
not
need to subclass the original class and to override all methods, and I
avoided the need to change the test every time I add a new method
to the original class.
So, I think the "active" usage of introspection is good too, but it
should
be used with care; it would be acceptable to me if it was disabled by
default
and if it required a compiler switch.
> Introspection also conflicts (well, requires careful consideration)
> with type checking, security, and abstraction, but I'm not going to go
> into that (I know that there are a couple of guys here who have
> written theses on related subjects).
This is interesting, if you have a reference, please let me know.
> Introspection also interferes with control flow optimizations. Such
> optimizations are very im****tant for making SML programs run fast.
Uhm ... examples?
> Also, I think that Common Lisp would probably be a good
> fit to your ideology --- you might want to take a look at it.
Yeah, you hit the nail on the head. Even if I have no practical
experience with Common Lisp (I think I played with Slime for a weekend
or so a few years ago) I am very used to the Lisp way of incremental
development, having programmed both in Scheme and in Python. This is
why I am not considering MLton: I simply cannot live without a REPL.
The ability to define new functions in a running program and to see
their effect immediately is a big productivity boost, especially when
you are developing user interfaces. For instance, at work, among other
things, I am developing web applications using Paste (a Python
library). Paste monitors all the modules im****ted by the program (and
by "all" I mean *all* modules, even the ones im****ted indirectly; in a
Web application this can easily mean hundreds of different modules)
and when I change any of them it reloads it, so that I can immediately
see the changes on my browser. Of course this has a performance
penalty and it is disabled in production, but when developing I must
say that I am not perceiving any penalty: the reload works
instantaneously
and seamlessly (actually Python reload has its own shortcomings,
but in practice it seems to work pretty well with Paste). I am sure
Lisp frameworks can do the same, as Smalltalk can do the same,
and I think even Ruby. Probably Alice can do the same in the ML
world, but I have yet to try.
Notice the big difference between a live system, in which I can even
introspect just entered functions which are not yet saved in the
file system, and a static do***entation tool grepping the source
code. There is no comparison.
> Really, you can't have everything. I can easily imagine, and have seen
> several times in other contexts, the opposite of your argument. I've
seen
> people wondering why it takes forever to start an application or why
> binaries are so large. Heck, I've personally had the "pleasure" of
using
> a few (Java) applications that were simply ridiculously slow, both at
> starting up and during normal operation, even with a rather powerful
> machine (this was actually quite recently).
It is easy to talk about Java. But Scheme, Common Lisp, Perl, Python
and Ruby
and possibly others have all the introspection and dynamic features
you can
imagine and still pretty much decent startup times.
> Compared to C++, SML makes it significantly easier to define and use
> abstractions both in the small (perhaps especially in the small) and
> in the large. Fortunately, there even exists a compiler that can
> eliminate many kinds of abstraction penalty. So, unlike with many
> other high-level languages, you can actually use such abstractions in
> performance critical sections of your application. So, optimizations,
> to me, are an enabling factor. Optimizations enable me to write code
> as I want to write it. Not the other way around.
An interesting point of view, but I am still convinced that one can
have
*both* abstraction and efficiency without loosing introspection and
interactivity, as Common Lisp shows. Alternatively, I am fine with
using a different language for parts of my application: if I need to
talk with a database, I am happy with having some SQL in my codebase,
and if I need efficiency I am happy with having some C in my codebase.
The im****tant thing for the main language is to play well with the
sublanguages (i.e. good database drivers, good foreign function
interface, etc.)
Michele Simionato
|
