Subject: Re: about run-time class (type) checks... From: Erik Naggum <erik@naggum.no> Date: 1998/12/05 Newsgroups: comp.lang.lisp Message-ID: <3121821477157482@naggum.no> * David Bakhash <cadet@bu.edu> | This is really evil, because I would think that declarations + generic | function calls can expand into invoking the right method, despite what | you said about subclasses, and that feature that Dylan has that CLOS | doesn't. | | Are there reasons that CLOS decided not to add that feature (i.e. sealing | a class)? What are the drawbacks? I recall seeing something like this | in Java, suggesting that it's there to allow for significant | optimizations. sealing is great for a language and environment where most of the hard stuff is done in the compiler and the program just _runs_. sealing is nigh evil for a language and environment where most of the hard stuff is done at load- or run-time and programs _evolve_ during their lifetime. the problem is that just as we have no way to make a variable "unspecial" because of the impact on the already-compiled code, there is probably no sealing because it would be necessary to have an "unseal" mechanism, too, and that would impact already-compiled code just like special bindings. the same goes, incidentally, for other (global) proclamations. if you declare a function's signature, should it still be possible to redefine it with, say, an additional optional argument, or with new argument types? which types should it be optimized for? should we have an UPGRADED-ARGUMENT-TYPE function? I use Common Lisp for a reason. high performance is nice, but when its absence becomes a significant hurdle for an application, I have already figured out _where_ it matters the most by writing everything in Common Lisp and profiling the application. like, today, I reimplemented a _tiny_ part of my application as a 30-line C program, and also changed the algorithm to reduce the traffic across the interface (a pipe -- it has to be running in a separate process). it wasn't the kind of thing Common Lisp is good at, but the fact that this trivial C program takes a huge load off of the Lisp scheduler and leaves it to Linux to deal with, also means that the rest of the application can now become more complex before we need to upgrade from the 133 MHz Pentium it is currently running on. (the _only_ reason we use that kind of machine is that we have lots and lots of them. because such hardware is dirt cheap, it is also expected to die, so we use two of them in parallel, instead. we're in the curious position that the hardware may crash and burn, but the software must be kept running without noticeable interruption. this is not the kind of stuff you do in six months in C, but that's what it has taken me to do it in Common Lisp, and only now am I beginning to worry about performance. a 133 MHz Pentium isn't worth shit these days, but thanks to Linux and Allegro CL, a very significant investment in hardware can now have a _much_ longer life-span. the savings on the hardware side almost pays for my work. who'd've thought _that_ about Common Lisp?) oh, one other thing -- by discovering this tiny CPU-intensive part, we were able to obtain a ten-fold overall system performance increase. since we had about the same factor when going from the old system to the new, the _observable_ response times have dropped to less than 100 ms, compared to 3 to 10 seconds in the old system. now, it wouldn't take a genius to spot the CPU-intensive part, but it did take Lisp to isolate it so cleanly and enable the ten-fold increase in performance. C coders just don't _do_ what what my hybrid solution does, anyway. so, for me, high performance computing on dirt cheap hardware comes with Lisp, and low performance computing on more expensive hardware was what C gave us. and isn't it perfectly ironic that because I _don't_ worry about high performance, _that's_ what I get, while the dude who wrote the previous version in C was mortally afraid of wasting cycles, and so wrote a system so slow it had to be replaced? the strangest thing is that most of what you really want from life obey the same apparent contradiction. I'm not sure how much sealing classes would have helped in my scenario. #:Erik -- The Microsoft Dating Program -- where do you want to crash tonight?