michele.simionato@[EMAIL PROTECTED]
<michele.simionato@[EMAIL PROTECTED]
> wrote:
> On Dec 2, 8:21 pm, Vesa Karvonen <vesa.karvo...@[EMAIL PROTECTED]
> wrote:
[...]
> 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.
Sure, *completely* passive usage, for stuff like debugging, seems
basically fine. But introspection isn't the only way to do such things.
The usual objection I have with excessive need of debugging is that it is
a symptom of problems with writing working code. I rather put more effort
into static checking (typing) and testing than debugging, because they are
investments that have lasting value, while a debug session is a one-time
effort for hunting a particular bug and doesn't help to reduce the number
of bugs introduced into the code in the first place.
> 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. [...] 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.
It is difficult to say without actually seeing your code, but if you are
just testing a generic logging framework, then I would think that you
could just write a simple test case for it separately. Shouldn't be much
more involved than the 5-6 lines of introspection code.
> > 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.
Here is one http://lambda-the-ultimate.org/node/219
.
> > Introspection also interferes with control flow optimizations. Such
> > optimizations are very im****tant for making SML programs run fast.
> Uhm ... examples?
Here is an example. Suppose the introspection facility provides the
ability to call any (accessible) function at run-time. Now, suppose then
that there is a function that is only called from a single place in the
program. Large programs typically have many such functions. Sometimes
even in performance critical inner loops. There is an optimization called
contification (http://mlton.org/References#FluetWeeks01)
that replaces a
function called from a single place (or, more generally, one that always
returns to the same place) with a continuation. You could think that
instead of using "call + ret" the compiler uses "jmp + jmp" to call that
function and return to the caller (this is a simplistic explanation of the
optimization). That optimization becomes invalid. IOW, you can't just
transform the function to jmp to the single return point. Instead of just
applying the optimization, the compiler would have to do something to
cater for the introspection facility to make it possible to call the
function from multiple places. Of course, this is just a single example.
It doesn't take a lot of common sense to see that introspection really
does interfere with optimizations.
> > 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.
BTW, I have programmed in Scheme quite a bit (both professionally and
on my own time). I know enough about Python to say that it isn't the
kind of language I would particularly like to program in. (The same
goes for Perl.)
> The ability to define new functions in a running program and to see
> their effect immediately is a big productivity boost [...]
Yes, I know. In some cir***stances it can be quite useful. Most SML
implementations provide you with a REPL that does let you enter new code
interactively. A REPL alone, can boost productivity a lot, because it
gives fast feedback. I use SML implementations with a REPL on a daily
basis to develop code. Aside from Alice ML, I think that with SML/NJ +
(slightly modified) CML, you might even be able to productively modify a
running system. Poly/ML 5.1, which sup****ts OS threads, would probably
also make it possible. Compared to something like Common Lisp, the main
difference is that you need to explicitly specify which functions you want
to be able to replace at run-time, because bindings in SML are immutable.
> > 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.
From what I've seen, like OCaml, some Common Lisp implementations can also
be used as assemblers with named variables, which means that if you need
good performance, you can get it by writing manually tweaked, imperative,
low-level code. The same applies to some Scheme implementations and then
there is also Stalin, which gives very good performance even for
high-level code. However, from what I've seen, the run-time performance
of Perl, Python and Ruby is disappointing. I doubt (please surprise me)
that one could get withing a factor of 10 of the performance of the kind
of code I wrote in my post
http://groups.google.com/group/comp.lang.functional/msg/5a30908fdef3bcd7
using the *same* kind of programming techniques (transliterate my code) in
Perl, Python, or Ruby. Note that the main program itself, reading input
from stdIn, is not representative. It is there just to make sure that the
loop isn't compiled away. IOW, I'm not talking about IO bound
computations. The kind of basic vector operations implemented in my code
sample would be used for stuff like real-time animation of (game) objects
(stored in memory), physics, and collision detection which can easily
become performance critical when you have lots of objects.
> 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.
Common Lisp gives fairly good performance, good enough for many uses,
but I must challenge you to transliterate my vector arithmetic example
to Common Lisp. There really are many reasons as to why a language
like Common Lisp is much more difficult to compile to efficient
machine code. If there is a Common Lisp compiler that can *safely*
optimize high-level functional code as well as MLton, then I would be
pleasantly surprised. Just the simple fact that any top-level binding
might be mutated at almost any point (any time you call a procedure
that the compiler doesn't know) makes many optimizations significantly
more difficult to perform *safely*. That is why you can declare the
level of safety you want (UGH!) in Common Lisp (or at least some CL
implementations). Unless you have the whole program, and I'm not
aware of any whole program compiler for Common Lisp, you can't safely
evaluate even something as simple as the expression (+ 1 2) statically
in Common Lisp. But, really, I have nothing against Common Lisp. It
has some features that I find interesting. However, being amenable to
static analysis is *not* one of the features of Common Lisp.
I have spent a lot of time over the years tuning code in various
languages. In particular, I would estimate that I've spent about 5
man-years programming mostly in assembly language on the MC68000/20
and 386/486 and Pentium processors (I've also written small amounts
assembly language code for other processors, e.g. the SH-4). Fifteen
years ago I could list all the instructions of MC68000 from memory
along with the number of clock cycles they take to execute. Frankly,
while I've had a lot of fun tuning short a snippets of code, I really
think that the time has come to spend time on other things. I really
don't want to program in a language and with a compiler that requires
one to forget high-level programming techniques for performance
critical parts of the program. (Unless the program is not really
performance critical, so performance doesn't matter.) The compiling
techniques that let you mostly forget manual code tweaking are already
available. I don't want to waste my life doing the work of a machine.
> 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.
Well, I certainly don't object to having a bit of SQL and a little bit
of C in an application for interoperability with existing
infrastructure. I wouldn't even mind having a scripting language (it
could even be SML) in an application for writing extensions. However,
I really do think that it is best to write the core of an application
pretty much in a single language. I also really don't want to spend a
lot of time programming in C.
> 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.)
I agree about the FFI. Using a FFI you can implement the database
binding if you need it. Not all apps need a database. Incidentally,
during the most of my career, I've worked on software (real-time games
for desktop machines and game consoles) in which traditional databases
are useless. (A traditional database might be useful in some network
games, but that is still likely to be a relatively small part of the
game.) A good FFI is crucial for a high-level language. This is also
one of the reason why I like MLton. It provides a straightforward
bidirectional FFI between SML and C
(http://mlton.org/ForeignFunctionInterface).
MLton also provides
ML-NLFFI, which is a higher-level, type safe FFI for calling C and
manipulating C objects from SML. While I think that ML-NLFFI could
still be improved significantly, it eliminates most of the boilerplate
code you typically need to write manually when using typical low-level
FFIs.
-Vesa Karvonen
|
