I've tried the rather young GTK-XEmacs which is a port of the
Xt-Parts of XEmacs to the GTK Toolkit.
This is not only for better look because this port includes EmacsLisp
access to a lot of the GTK-Widgets.
AFAIK the GTK-XEmacs will also run under Windows! (Using the GTK port to
windows)
Think of popup-menus, Or Tooltips and so on!
We could e.g use GTK Tooltip to show the arguments of a Function in a way
often seen in the "Visual" IDEs. We could include Process-Browsers,
Class-Browser and so on with nice looking GUIs.
Just some thoughts...
Regards,
Jochen
To the question in the subject line: NO!
Jochen Schmidt <···@dataheaven.de> writes:
> I've tried the rather young GTK-XEmacs which is a port of the
> Xt-Parts of XEmacs to the GTK Toolkit.
> Think of popup-menus, Or Tooltips and so on!
> We could e.g use GTK Tooltip to show the arguments of a Function in a way
> often seen in the "Visual" IDEs. We could include Process-Browsers,
> Class-Browser and so on with nice looking GUIs.
Firstly, I suspect (but don't know, so do correct me if this is
wront) that this doesn't work on plain vanillay GNU emacs. So
you lose a big chunk of your audience right there. Audience == mindshare,
the single most important resource if you want ILISP to survive.
Secondly, look at the things ILISP *should* support but doesn't,
e.g. a really tight integration with multithreaded lisps. Those
who have used both ILISP and Franz's eli package with ACL will know
what I mean. It's *so* easy to hang ilisp with lispworks, it's sad.
(And on Windows, it's even worse than Linux.)
Oh, and these are not sour grapes, I use ILISP daily, and have reported
and sent patches to the maintainers for Lispworks specific issues.
I just wish it was tighter and nicer to use. Hell, even the basic
"list all callers" type functions don't work right yet...
Forget fancy menus, let's get to work on the basics _first_.
BTW -- I think this discussion may be more appropriate to the mailing list.
Alain Picard
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
From: Kent M Pitman
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <sfwpudmljdh.fsf@world.std.com>
Alain Picard <·······@optushome.com.au> writes:
> Secondly, look at the things ILISP *should* support but doesn't,
> e.g. a really tight integration with multithreaded lisps.
I'm just watching this discussion from the outside, since I don't
personally use ILISP, but I have to ask: to what degree is this a
problem with ILISP and to what degree is it a problem with the
individual lisps (e.g., LispWorks). That is, does ILISP have some
generic interface that LispWorks is simply not implementing (that
would sound like a LispWorks bug) or is LispWorks expected to come up
with some custom interface to accomodate the lack of a standard
interface (that would sound like an ILISP bug).
> Those who have used both ILISP and Franz's eli package with ACL will
> know what I mean.
Actually, on balance, I've used ELI and I'm not sure what you mean at
all.
Not to knock the Franz GUI builder, which is a really cool tool
generally, but the editor integration with it is the one huge gaping
wound in that tool, or, at least, was at the time I last used it two
years ago. The problem was that you HAD to use Emacs (because there
was no native tool) when doing development for the non-gui-builder
stuff and you HAD to not use Emacs (because there was a native tool
that you couldn't not use) for the gui-builder stuff. I wanted the
gui builder when I clicked on something to send me to Emacs, but it
would not. And consequently, since that was central to my activity,
any time I found myself in Emacs meant I was not in the GUI builder
where I wanted to be. So it the Franz solution had plenty of its own
problems to deal with. I sent detailed bug reports on this, but
wasn't on a support plan, so it's not like I was entitled to fixes.
But I hope they heard me and have since repaired this mess, which gave
a very haphazard feel to the GUI. My sense was, at the time, that the
problem was that their developers did not use the GUI builder
themselves and so did not adequately appreciate the importance of its
having an integrated editing solution.
So it we're probably playing the game of the blind men and the elephant
here, but I personally see the issue this way: the Franz product has
(or had--someone please correct me if my data is stale) two editor
interfaces, neither of which is capable of being used consistently
as the one-and-only-one elected interface for one's entire session.
One sometimes finds oneself in simple windows editor boxes with barebones
paren-matching and little more and is pretty much forced to be there;
one sometimes findds oneself in emacs and is pretty much forced to be
there. Choice is/was absent uniformly. By contrast, to me, the
LispWorks product offers a built-in integrated editor that is uniformly
available throughout the product and which I would no more expect them
to apologize for "not being Emacs" than I would expect Digitool to
aplogize for FRED (or whatever their editor is called) or Symbolics for
Zmacs. Too bad about the incompatibility, but it's still a great thing
to have integration/consistency/support. Plus on top of this, LispWorks
provides ALSO a choice to use ILISP, which I also think is great for
people who want it. Maybe it's got some bugs in the interface, but still
for all the whining I've seen here about how some people wish it was
ELI, no one has made a case that this is a LispWorks bug in the managing
of ILISP, rather than merely a decision to limit the level of support
for the interfaces to whatever externally maintained libraries people have
said they want supported. Is there a public ELI and an interface
LW could adhere to in order to be ELI compliant as well? If not, how
much work is LispWorks obliged to do in the editor area before it can go
about the business that I think it should be doing like making sure it has
all the right PROGRAM interfaces.
PROGRAM interfaces are going to make or break products. USER
interfaces are something you can get used to. I'd rather not use
Emacs from the outside, but I could have gotten used to ELI, with
time, in the ACL offering if only I could have used it consistently in
my work and not have been half-time in that and half-time in other
windows. Given the obviously limited resources of the Lisp community,
I think it's unfair to tell vendors they are obliged to us to do
infinite cosmetic cr*p, and not to understand that
every time we tell them to do that, we are asking them to NOT do something
else of great importance. Nothing comes free. Every feature we ask for
is at the cost of another feature we didn't get. And so I think it's critical
that we not just whine about not getting the ideal environment of our dreams,
but stick to saying when there is a non-compliance of interface or an
advertised feature that is not present. And it is also critical to identify
in a cooperative situation which party is failing to cooperate.
Bandying about the terms ILISP and ELI and LispWorks in one sentence
and bundling it up with "you'll know what I mean" doesn't seem
adequate to me. I just don't know what you mean, and I think you're
confusing other people too. Your message comes across like "Franz
does it all right and LispWorks does it all wrong". I have the
vaguest impression that LispWorks is actually maybe not at fault and
that ILISP either needs some extension work and/or a fuller interface
to connect to, but I can't tell from what you say. It sounds like you
want it to annex some ELI stuff but that it hasn't, but I can't tell.
Let me be clear, so that no one thinks this was some veiled attempt to
bash the Franz product: I really like the Franz GUI builder. It is not
matched by the LispWorks product; there is no corresponding component.
(The GUIs it builds are pretty much analogous to the CAPI guis, but there
is no drag-and-drop CAPI GUI builder, and that's a shame.) It's because
I really liked the Franz GUI builder that I was so sad that the editor
interface to that thing was so disconnected from Emacs. I wanted to
(setq *preferred-editor* 'emacs) or some such thing and have it know to
use Emacs buffers instead of myriad little awful Microsoft default editor
boxes. But with or without the Franz editor inconsistency products, I
don't think the Franz product is in any way a substandard offering of
Common Lisp. I think that both LispWorks and Franz are fine commercial
offerings of production quality Common Lisps. I just tire of seeing this
discussion going on which to someone who'd never seen either one would
make it look like ACL implements multi-processing and LispWorks doesn't
(which simply isn't so) or that ACL has a good editor interface and
LispWorks doesn't (which also isn't true). That may not have been your
intent, but your posts come across that way. And I wanted to add some
balance, that's all.
Mostly I would understand completely if Franz didn't care about the editor
beyond what it has now, whether or not I use their product, and I feel the
same about LispWorks, which I do use. Lisp has a hard time in the
marketplace and the wars are not against the other lisp vendors, they are
against the other languages. Winning those battles, I think, won't be
done at the level of editors. Or if it is, it won't be done by choosing
either Franz' Emacs or LispWorks Editor. If anything, the Franz choice of
that doofy little Microsoft editor will probably please more potential
customers. But hopefully the real work by both vendors will go into
programming tools which can make application products shine, and people like
us will stop whining about inconsequentialities so they can focus on those
things they need to survive.
> It's *so* easy to hang ilisp with lispworks, it's sad.
> (And on Windows, it's even worse than Linux.)
>
> Oh, and these are not sour grapes, I use ILISP daily, and have reported
> and sent patches to the maintainers for Lispworks specific issues.
> I just wish it was tighter and nicer to use. Hell, even the basic
> "list all callers" type functions don't work right yet...
>
> Forget fancy menus, let's get to work on the basics _first_.
>
> BTW -- I think this discussion may be more appropriate to the mailing list.
WHAT mailing lisp? LispWorks? Franz? ILISP? I think the real problem with
your message is that you aren't specific about what you are reporting a bug
in and who you are talking to. As I've said many times, when you report a
bug, try to be specific (e.g., implementation and version if possible).
(My apologies that I don't have the implementation/version info for the
remarks I made about the Franz offering earlier; I returned the CD and don't
have a running version left behind so can't easily check. But I tried to
at least qualify the vendor and the time period as a substitute, and not to
assume it was broken for all time...)
Kent M Pitman <······@world.std.com> writes:
> > Those who have used both ILISP and Franz's eli package with ACL will
> > know what I mean.
>
> Actually, on balance, I've used ELI and I'm not sure what you mean at
> all.
Mulitple listener buffers, each in the same Lisp world.
At least, that's what I take it to mean.
> So it we're probably playing the game of the blind men and the
> elephant here, but I personally see the issue this way: the Franz
> product has (or had--someone please correct me if my data is stale)
> two editor interfaces, neither of which is capable of being used
> consistently as the one-and-only-one elected interface for one's
> entire session.
For what ACL costs, ACL should come with a monster CL XEmacs, with an
integrated ``GUI builder'' as you call it. But ACL's Common Windows
thing is still several generations behind what exists for Java and
even Delphi. I wouldn't expect much from it.
Still, iirc, I was using that whole Franz Common Windows IDE for a
bit, and recall that I could link it to my Emacs editor -- even on
NT. In other words, since it's socket-based, your editor (Emacs)
becomes the client, and so you can have both. So, you write your code
in Emacs (instead of some Notepad-like joke-of-an-editor) and still
use the GUI tools.
On a wild aside, I don't see why anyone would do the GUI development
part of any project in Common Lisp, given the existence of Corba and
Java. It's just not smart design. It's not web-friendly design
either, since applets can talk Corba, and can work in browsers without
expensive Lisp stuff on every computer. (of course, with ACL, they
already figured that in, and charge you for it, making all
client-server designs almost impossible to pay for themselves).
Basically, if you want to build a GUI program, then I personally
recommend:
1) Buy LispWorks Enterprise: $2,000 (includes Corba, SQL, ODBC, etc.)
2) Corba-enable your application with some IDL interface.
3) Write the GUI part in Java.
This is the ultimate way to develop *all* applications -- especially
3-tier apps. You have a database server, your Lisp for logic, and
Java for connectivity, portability, and nice GUI tools. It's also the
nicest on your budget. The *worst* thing you can do for your budget,
as well as doing more work, having less portability, and probably a
less robust system is:
1) buy ACL with AllegroStore and Common windows, etc.
2) server-enable that however you want (e.g. Corba)
3) write the GUI client with ACL's Common Windows
This solution will probably cost on the order of $100,000 just for the
Lisp tools, considering that you'd like to distribute it to a handful
of clients. Is it worthit? God NO, and for this particular scenario,
I doubt anyone at all has implemented a system in the above
configuration. But if one *did* want to do so, I'd say that $5k would
be about right, and even that's pushing it way too hard.
> One sometimes finds oneself in simple windows editor boxes with
> barebones paren-matching and little more and is pretty much forced
> to be there; one sometimes findds oneself in emacs and is pretty
> much forced to be there. Choice is/was absent uniformly. By
> contrast, to me, the LispWorks product offers a built-in integrated
> editor that is uniformly available throughout the product and which
> I would no more expect them to apologize for "not being Emacs" than
> I would expect Digitool to aplogize for FRED (or whatever their
> editor is called) or Symbolics for Zmacs. Too bad about the
> incompatibility, but it's still a great thing to have
> integration/consistency/support.
I'd take a broken Emacs over XEmacs over *any* of these editors. Note
that I like the menus and other features they have. But they're not
Emacs, and sometimes, even the little things that don't work in the
wanna-be Emacs can be very frustrating.
I much prefer ACL's Emacs-centric design for this. They didn't
re-invent the editor; they just used the best one out there.
> Plus on top of this, LispWorks provides ALSO a choice to use ILISP,
> which I also think is great for people who want it. Maybe it's got
> some bugs in the interface, but still for all the whining I've seen
> here about how some people wish it was ELI, no one has made a case
> that this is a LispWorks bug in the managing of ILISP, rather than
> merely a decision to limit the level of support for the interfaces
> to whatever externally maintained libraries people have said they
> want supported. Is there a public ELI and an interface LW could
> adhere to in order to be ELI compliant as well? If not, how much
> work is LispWorks obliged to do in the editor area before it can go
> about the business that I think it should be doing like making sure
> it has all the right PROGRAM interfaces.
If Xanalys chooses to partially support ilisp, well, I'd say that's a
smart move. If they wanted their own branch of ilisp that they *only*
guaranteed would work with LispWorks, I'd be ecstatic, given the
problems I've had with ilisp for the past few years.
> I'd rather not use Emacs from the outside, but I could have gotten
> used to ELI, with time, in the ACL offering if only I could have
> used it consistently in my work and not have been half-time in that
> and half-time in other windows.
I don't get this. If there's one editor that you *can* use
consistently with other development environments, it's Emacs.
> Given the obviously limited resources of the Lisp community, I think
> it's unfair to tell vendors they are obliged to us to do infinite
> cosmetic cr*p, and not to understand that every time we tell them to
> do that, we are asking them to NOT do something else of great
> importance. Nothing comes free. Every feature we ask for is at the
> cost of another feature we didn't get. And so I think it's critical
> that we not just whine about not getting the ideal environment of
> our dreams, but stick to saying when there is a non-compliance of
> interface or an advertised feature that is not present. And it is
> also critical to identify in a cooperative situation which party is
> failing to cooperate.
Only the vendors themselves know about all the different features that
are being asked for. I trust that they know what they're doing, and
will choose in right order, and things will eventually get done.
Personally, I think database interface and connectivity are of utmost
importance these days, and so I think Xanalys has done a phenomenal
job. Still, their product is lacking, but the shortcomings are being
addressed. I agree that the comfort level of programmers is not
nearly as important as the problem solving ability of the Lisp. But
given that Lisp is already quite powerful as it is, it would be nice
to take a step back sometimes and note that today's Lisp IDEs don't
compare to what's out there for other languages (except for MCL, which
I've never seen, but have heard is phenomenal).
> Bandying about the terms ILISP and ELI and LispWorks in one sentence
> and bundling it up with "you'll know what I mean" doesn't seem
> adequate to me. I just don't know what you mean, and I think you're
> confusing other people too. Your message comes across like "Franz
> does it all right and LispWorks does it all wrong". I have the
> vaguest impression that LispWorks is actually maybe not at fault and
> that ILISP either needs some extension work and/or a fuller
> interface to connect to, but I can't tell from what you say. It
> sounds like you want it to annex some ELI stuff but that it hasn't,
> but I can't tell.
ELI can potentially be ported to LispWorks, but that's not even close
to the solution. I think the solution is to either start fresh or
fork off ilisp to more competant people. My comfort level with the
editor and development environment severely affects my efficiency, and
so while you many not care so much, I care a lot, and I'm sure others
do too. The more interactive you are when programming, the more you
care. If you just open a file buffer, write a file, then compile and
load it, then you won't care as much if you program in much smaller,
interactive pieces.
But despite all of this, the LispWorks editor is very good. But does
it have the `C-x 2' feature? I never was able to split the window,
and that's probably why I preferred Emacs.
> Mostly I would understand completely if Franz didn't care about the
> editor beyond what it has now, whether or not I use their product,
> and I feel the same about LispWorks, which I do use. Lisp has a
> hard time in the marketplace and the wars are not against the other
> lisp vendors, they are against the other languages. Winning those
> battles, I think, won't be done at the level of editors. Or if it
> is, it won't be done by choosing either Franz' Emacs or LispWorks
> Editor. If anything, the Franz choice of that doofy little
> Microsoft editor will probably please more potential customers. But
> hopefully the real work by both vendors will go into programming
> tools which can make application products shine, and people like us
> will stop whining about inconsequentialities so they can focus on
> those things they need to survive.
Let's agree that there's a balance of what's important. I agree that
I'm sufficiently happy with my broken ilisp that I'd much rather have
better programming interfaces.
Still, I consider a debugger as part of user interface into a
development environment, and neither of these Lisps accomodates my
debugging needs. The elisp debugger and gdb are better.
> BTW -- I think this discussion may be more appropriate to the
> mailing list.
> WHAT mailing lisp? LispWorks? Franz? ILISP? I think the real
> problem with your message is that you aren't specific about what you
> are reporting a bug in and who you are talking to.
It's obvious that he means the ilisp list, but I suppose that even I
have been desperate, and have contacted Harlequin for ilisp support
(which, to no surprise, they provided). Never hurts to ask, I guess.
dave
"David Bakhash" <····@localhost.localdomain> wrote
> On a wild aside, I don't see why anyone would do the GUI development
> part of any project in Common Lisp, given the existence of Corba and
> Java. It's just not smart design. It's not web-friendly design
Because we don't like Java and prefer to write in Lisp could be one reason.
Or because we need specific stuff like OpenGL for instance.
> either, since applets can talk Corba, and can work in browsers without
> expensive Lisp stuff on every computer. (of course, with ACL, they
> already figured that in, and charge you for it, making all
> client-server designs almost impossible to pay for themselves).
> Basically, if you want to build a GUI program, then I personally
> recommend:
>
> 1) Buy LispWorks Enterprise: $2,000 (includes Corba, SQL, ODBC, etc.)
> 2) Corba-enable your application with some IDL interface.
> 3) Write the GUI part in Java.
>
> This is the ultimate way to develop *all* applications -- especially
> 3-tier apps. You have a database server, your Lisp for logic, and
> Java for connectivity, portability, and nice GUI tools. It's also the
> nicest on your budget. The *worst* thing you can do for your budget,
> as well as doing more work, having less portability, and probably a
> less robust system is:
>
> 1) buy ACL with AllegroStore and Common windows, etc.
> 2) server-enable that however you want (e.g. Corba)
> 3) write the GUI client with ACL's Common Windows
>
> This solution will probably cost on the order of $100,000 just for the
> Lisp tools, considering that you'd like to distribute it to a handful
> of clients. Is it worthit? God NO, and for this particular scenario,
> I doubt anyone at all has implemented a system in the above
> configuration. But if one *did* want to do so, I'd say that $5k would
> be about right, and even that's pushing it way too hard.
1) Buy LispWorks. The Enterprise version if you need it. (or ACL or Corman
Lisp according to your taste and/or budget)
2) for windows apps : Write the GUI part in Lisp using Win32 API through
foreign calls.
2bis) for "run everywhere" apps put a (D)HTML interface and use one of the
numerous possibilities to process HTTP requests in Lisp. (from apache with
mod_lisp to CL-HTTP)
3) have fun
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "David Bakhash" <····@localhost.localdomain> wrote
>
> > On a wild aside, I don't see why anyone would do the GUI development
> > part of any project in Common Lisp, given the existence of Corba and
> > Java. It's just not smart design. It's not web-friendly design
>
> Because we don't like Java and prefer to write in Lisp could be one reason.
> Or because we need specific stuff like OpenGL for instance.
Do you think I like Java? It has nothing to do with likes, or
anything else. Most serious projects have teams of people. Java
people are all over the place, and arn't nearly as costly or as rare
as Lisp programmers.
Mentioning OpenGL is pretty absurd to me, considering that Java, Perl,
C, and C++ *all* have interfaces to other software products and
laguages.
If you want to talk about interoperability, consider that Java has
JDBC/ODBC, its own messaging and transaction system, JavaComm, Java
SmartCard programming (JCRE), and heaps more -- not to mention that
*every* modern-day browser comes with a built-in Java runtime
environment. Any foreign function interface that Lisp might have Java
can easily have, and probably already does.
> 1) Buy LispWorks. The Enterprise version if you need it. (or ACL or Corman
> Lisp according to your taste and/or budget)
CormanLisp seems to be a neat option if you're gonna live in the
Windows environment forever, or (who knows) when some Wine/Willows
project gets out of alpha. ACL, again, is a just a rip-off. The most
potentially useful thing that Franz offers is AllegroStore, but With
the latest features from Xanalys, you can use a real RDBMS with nearly
as much power as Franz's AllegroStore (and in some cases more). Will
it be as fast? Depends on the data models and overall structure of
your program. But at least you can use some of the amazingly powerful
yet free RDBMSs, e.g. InterBase, PGSQL (these two being completely
free and open-source). And, by using an ODBC-compliant RDBMS, other
database-backed applications can share that database easily, and
without doing very nonstandard, difficult things that very few people
understand. I'm actually *happy* that a year or so ago when I called
Franz for AllegroStore that I couldn't afford it. It's the best thing
that ever happened to me, because the application that I was working
on would have suffered with AllegroStore -- just because *any* other
scripts and programs that wanted to interact with the data would have
to deal with this object database, and that's just not easy.
Furthermore, most (hell, almost all) serious companies already
maintain a serious database, and so why make them have to maintain
*two* databases?
The bottom line is that good design is not just about programming;
it's about planning for the future, for dealing with other
programmers, other technologies, other systems, other environments.
Lisp is a great language, but as far as graphics are concerned, while
I think that Common Lisp can potentially offer the best interface to
graphical manipulation, it's not the strength of Lisp, and it's a
huge expenditure that is (in my opinion) beyond the scope of the the
Common Lisp resources.
dave
David Bakhash <····@localhost.localdomain> writes:
> Furthermore, most (hell, almost all) serious companies already
> maintain a serious database, and so why make them have to maintain
> *two* databases?
Because there's no DBMS (that serious companies already
maintain - mostly RDBMS) that allows us to store the data
types we use usually and naturally.
If you use a persistent lisp object system, and some other
guy would like to refer your data, then you can export it
using ODBC or something. But I hate to design my application
data structure(or interface) in RDB-semantics.
I think a persistent object system is a part of a
application, so using AllegroStore(for example) doesn't
force our customer to maintain *two* databases.
--
(define (KURODA Hisao)
(email ······@msi.co.jp))
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m37kzm21pi.fsf@alum.mit.edu>
Hey,
This is something that you probably havn't thought through completely.
A lot of the problems and questions you raise are indeed solved
elegantly using very affordable Lisp systems. Here goes...
>>>>> "kuroda" == KURODA Hisao <······@msi.co.jp> writes:
kuroda> David Bakhash writes:
>> Furthermore, most (hell, almost all) serious companies already
>> maintain a serious database, and so why make them have to maintain
>> *two* databases?
kuroda> Because there's no DBMS (that serious companies already
kuroda> maintain - mostly RDBMS) that allows us to store the data
kuroda> types we use usually and naturally.
I guess I've just learned to become more comfortable with relational
databases, and coercing my data into that structure. I think RDBMS
technology is excellent, reliable, and that SQL is very well-designed.
kuroda> If you use a persistent lisp object system, and some other
kuroda> guy would like to refer your data, then you can export it
kuroda> using ODBC or something. But I hate to design my application
kuroda> data structure(or interface) in RDB-semantics.
Consider what EJB are generally used for. By now, you've probably
heard of `business objects'. These are objects in Java which are
stored persistently in relational backends. These objects and their
interfaces are distributed nicely across networks, and not only
simplify systems, but help make them more scalable.
If you have a good object-relational interface, then you can do
wonders. For example, LispWorks Enterprise gives you the SQL package,
with excellent object-relational mappings, and Corba, so you can
create interfaces for these objects.
I think that maybe within a couple of years someone will have a nice
macro language to describe objects and object relationships which is
not only well-integrated with Lisp, but which is efficient, and which
handles not only the data manipulation (e.g. queries, updates,
deletes, inserts), but the data definition, so that even the SQL code
that generates the tables is automatic.
kuroda> I think a persistent object system is a part of a
kuroda> application, so using AllegroStore(for example) doesn't force
kuroda> our customer to maintain *two* databases.
AllegroStore, in theory, is a great idea. But when you add it all up,
i.e.
o a cut throat company
o a very expensive piece of software
o a database to which few applications can easily interface with
Plus (I'm guessing -- could be wrong) an inferior query language, you
are probably worse off than you'd be with the object-relational
mapping that you get with LispWorks.
Persistence is a big deal. Distributed computing is a big deal.
There are pretty good solutions to these problems these days. They're
not turnkey just yet, but they're getting closer.
I wish every compeditor used ACL + AllegroStore. They'd be forced to
sell their products and services for much more, and I'd be able to
undersell them, and with a more sound framework. I've used
LispWorks's persistent object system with MS SQL Server, Borland
InterBase, and Oracle by now, and on MS, Linux, and Solaris.
Interbase is free, Linux is free, MS SQL Server is relatively
inexpensive, and LispWorks is reasonably affordable for server-side
applications.
What about you? I hope you're not one of the suckers paying out 5% of
your gross revenues to Franz. At least, that's what their regional
sales rep told me. It's funny that at the time, I was so upset, and
now I realize that had their software been free, it would have been a
mistake.
dave
David Bakhash <·····@alum.mit.edu> writes:
> kuroda> Because there's no DBMS (that serious companies already
> kuroda> maintain - mostly RDBMS) that allows us to store the data
> kuroda> types we use usually and naturally.
>
> I guess I've just learned to become more comfortable with relational
> databases, and coercing my data into that structure. I think RDBMS
> technology is excellent, reliable, and that SQL is very well-designed.
I've used RDBMSs quite a bit, and with various interfaces. I wrote a
Perl DB interface back when DBI was just starting, have used
Next/Apple EOF extensively, and designed/built USQL along with my
co-workers at onShore. While I've generally been happy with the use
of RDBMSs, I have repeatedly run into issues using them. These
include dealing with the simplicity of the type system built into the
SQL standard, failures of implementations to follow said standard,
rigidity in SQL relations, lack of standards for in-DB extensions,
lack of standard typing extensions, lack of logical constructs for
composing queries, and the high costs for complex queries across
tables (which is very important or object composition in obj->rel
interfaces). However, none of these have stopped me from working with
RDBMSs.
> Consider what EJB are generally used for. By now, you've probably
> heard of `business objects'. These are objects in Java which are
> stored persistently in relational backends. These objects and their
> interfaces are distributed nicely across networks, and not only
> simplify systems, but help make them more scalable.
I'm not sure we can say they simplify systems. Last I looked, which
was admittedly a year or so ago, it took several Java classes to
represent one "business object". Unless you using visual tools for
managing these objects, that's alot of code to maintain by hand, and
alot of fragility. I've worked with other object->relation interfaces
and EJBs are anything but simple in comparison to either EOF or USQL.
Their ability to make apps "more scalable" is questionable as well.
While it's true that SQL*Net and the normal mechanisms for accessing
RDBMSs from remote hosts do allow one to spread an application across
hosts, the overhead of maintaining some basic object "properties" for
the EJBs can be very costly. Maintaining object identity and data
integrity within a single process can be managed thru your mapping
framework, often by using the same object instance in memory for all
references to the DB. However, unless you application is largely
read-only, or has writes structured such that overwrites are not a
major problem, maintaining object identity has a high cost when you
have multiple processes manipulating the same objects. Using SQL
features, like table, or row, or attribute locking (the interface to
which is not shared between all DBs) can solve simple problems, like
stopping conflicting writes, but that's only part of the problem.
> If you have a good object-relational interface, then you can do
> wonders. For example, LispWorks Enterprise gives you the SQL package,
> with excellent object-relational mappings, and Corba, so you can
> create interfaces for these objects.
The package I mentioned before USQL, replicates and extends upon the
LW SQL package. I must admit to have never used the LW package, only
implemented it's interfaces (with some changes I think are
improvements).
I like to think of USQL as excellent, indeed it has done everything we
need for our database applications, but I'm afraid it's no match for a
real OO database with sufficient Lisp integration. There is no way
around the impedence between the relational model and the object
model. There are serious issues with object identity, object
cacheing, scheme mutability and versioning, mappings of object
hierarchies to tables, efficient representation of object relations,
flexibility in object schema mappings to relations, and mapping
simpler data types into tables while still allowing reasonable queries
against them.
The various obj->rel packages address these issues with varying
degrees of success. The EOF for instance using an "editing context"
to track all in memory object changes and manage transactions, cache
objects, as well as enforce string object ientity (within an EC only
one instance of an object is used to represent the set of rows in the
DB). USQL and I believe the LW SQL package do not enforce string
object identity, use the DBs transaction management, and punt on the
problem of object cacheing (relations however are cached once faulted
in). One think I dig about USQL is that one could build an editing
context abstraction on top of it, but with the EOF, getting rid of the
EC is difficult (tho not imposible).
All of these obj->rel mappings have considerable overhead in object
composition, particularly if objects span multiple tables. Joins must
be done, data must be sucked across the interface, SQL types must be
coerced into native types, and bookkeeping needs to be done in the
case of editing contexts.
Using an OO database with good lisp integration avoids many (not all
tho) of these problems. No need to coerce native types into SQL,
relations can be handle by references as opposed to queries, object
identity requires less bookkeeping, schema versioning is usually
handled for you, inheritence doesn't mean possible multi-table queries
for object composition, and data definition is simplified.
> I think that maybe within a couple of years someone will have a nice
> macro language to describe objects and object relationships which is
> not only well-integrated with Lisp, but which is efficient, and
> which handles not only the data manipulation (e.g. queries, updates,
> deletes, inserts), but the data definition, so that even the SQL
> code that generates the tables is automatic.
What about the USQL/SQL macros do you see as disqualifying them from
what you describe above? With both packages you use the
def-view-class macro to define your object, and it's table mappings at
the same time. There is a query language that is well integrated with
lisp, and allows both functional and OO access to the data.
Some of our extensions to USQL making OO access and querying easier,
we extended the [slot-value] sql operator to do automatic type
coercion of values, as well as just slot reference. You can quite
easily do all your work without dropping below the OO interface,
making you immune to changes in the object->table mapping, or
native->sql type coercions. Of course major changes may require
reworking of queries for performance reasons.
> What about you? I hope you're not one of the suckers paying out 5% of
> your gross revenues to Franz. At least, that's what their regional
> sales rep told me. It's funny that at the time, I was so upset, and
> now I realize that had their software been free, it would have been a
> mistake.
If AllegroStore was free, or even had a no-royalty distribution
license (along with the rest of the runtime), I would much prefer that
over the existing obj->rel systems for some applications (I'm a Free
Software advocate tho, so it would be a tough call now that USQL
exists). I must confess that it seems to me that you're attempting to
present a unfounded technical justification for your business
decision. There is no reason to be ashamed of making a design
decision based on cost and availability, just as there is no reason to
try and paint a sad picture of a very useful technology and paper over
the shortcomings of another one.
I'm not some Franz groupie, or even a pure OO advocate obsessed with
making it objects all the way down. I've made my living using and
writing obj->rel mapping packages in several languages, and still
enjoy working with/on them. However, I'm not going to go willfully
blind about their shortcomings.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m3itj5yu5p.fsf@alum.mit.edu>
>>>>> "craig" == Craig Brozefsky <·····@red-bean.com> writes:
>> Consider what EJB are generally used for. By now, you've probably
>> heard of `business objects'. These are objects in Java which are
>> stored persistently in relational backends. These objects and their
>> interfaces are distributed nicely across networks, and not only
>> simplify systems, but help make them more scalable.
craig> I'm not sure we can say they simplify systems. Last I looked,
craig> which was admittedly a year or so ago, it took several Java
craig> classes to represent one "business object". Unless you using
craig> visual tools for managing these objects, that's alot of code
craig> to maintain by hand, and alot of fragility. I've worked with
craig> other object->relation interfaces and EJBs are anything but
craig> simple in comparison to either EOF or USQL.
I was talking more about the Lisp version of this, which is probably
different from EJB. I was probably assuming that the Java
implementation (which I'm personally unfamiliar with -- especially
relative to such things in CL) would be similar to CL.
>> What about you? I hope you're not one of the suckers paying out
>> 5% of your gross revenues to Franz. At least, that's what their
>> regional sales rep told me. It's funny that at the time, I was so
>> upset, and now I realize that had their software been free, it
>> would have been a mistake.
craig> If AllegroStore was free, or even had a no-royalty
craig> distribution license (along with the rest of the runtime), I
craig> would much prefer that over the existing obj->rel systems for
craig> some applications (I'm a Free Software advocate tho, so it
craig> would be a tough call now that USQL exists). I must confess
craig> that it seems to me that you're attempting to present a
craig> unfounded technical justification for your business decision.
craig> There is no reason to be ashamed of making a design decision
craig> based on cost and availability, just as there is no reason to
craig> try and paint a sad picture of a very useful technology and
craig> paper over the shortcomings of another one.
I agree that these ODBMSs are much tighter, and can potentially
provide significant performance improvements. But there certainly is
a price you pay when your persistent data is not easily accessible
directly. Everyone knows how to read and interact with relational
data, and most programming languages and environments have
interfaces. This is what I was referring to when I was speaking of
the downside to things like AllegroStore.
I'll check out USQL, though.
dave
David Bakhash <·····@alum.mit.edu> writes:
> I was talking more about the Lisp version of this, which is probably
> different from EJB. I was probably assuming that the Java
> implementation (which I'm personally unfamiliar with -- especially
> relative to such things in CL) would be similar to CL.
Yes, the lisp packages are quite different from EJB, and the EOF
(Next/Apple). One thing I disliked about the EOF is that the text
describing the object model as mapped into the database, and the code
defining the classes where in seperate file. Add to this the fact
that you have .h and .m files and you end up having to update three
files when you make changes to your object model. Now the development
environment for EOF has an EOModeler tool which is a GUI for designing
your DB model, and it can handle the synchronization of these files to
a certain degree, but being an Emacs shop, all our work was done by
hand and elisp code.
Another way the EOF differs form the EJB is that it only takes single
class to represent a persistent object. It also has a neat protocol,
the key/value protocol whichmakes tying data from the DB into your
database and back thru your busines logic fairly easy. It's amazing
the way NeXT had such simple and usable solutions for things that the
Java and C++ world has built into gigantic bohemoths. The PDO,
portable distributed object, layer is a nice OO RPC mechanism that
works. Granted it doesn't have all the bells and whistles of CORBA,
but it's so much easier to use and comprehend.
> I agree that these ODBMSs are much tighter, and can potentially
> provide significant performance improvements. But there certainly
> is a price you pay when your persistent data is not easily
> accessible directly. Everyone knows how to read and interact with
> relational data, and most programming languages and environments
> have interfaces. This is what I was referring to when I was
> speaking of the downside to things like AllegroStore.
With regards to data accesability, obj->rel mapping does not always
preserve that. I have worked on one EOF project where the model was
very simple and people did quite alot of interaction with the
datastore at the SQL level for maintenance. It was a very large,
simple dataset, so SQL access and the tools available for SQL where
particularly useful.
However, on the project I'm working on now, using USQL, the object
model is much more complex, and has to be alot more dynamic. To
support the complexity, and dynamics, of the object model and its SQL
mapping we had to use alot of table layouts that would be quite alien
to the common SQL monkey. We could still manipulate the data in SQL.
In fact, the last major schema change we did used alot of complex SQL
because it was much faster than doing the migration at the lisp level.
But, an SQL monkey can't just hook up a reporting tool to the
datastore and expect to get meaningful results, in contrast to the
first project.
Another DB that I'm interested in is FramerD, www.framerd.org. It's a
frame datastore, which is good for storing data that is navigated
mostly by reference, like most object models.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m3pudcwaue.fsf@alum.mit.edu>
>>>>> "craig" == Craig Brozefsky <·····@red-bean.com> writes:
craig> Another DB that I'm interested in is FramerD, www.framerd.org.
craig> It's a frame datastore, which is good for storing data that is
craig> navigated mostly by reference, like most object models.
good to know, but with all the join-based overhead of relational
databases, I doubt that you'll *ever* do much better than a good
relational database. I *love* InterBase, for example, and it handles
huge amounts of data relatively fast, provides all of the advanced
features that make relational databases useful, and ways to improve
performance that can, in the end, compensate for everything else.
I looked over USQL, and I think it's impressive, though it's not as
complete as what I've personally gotten to work with regarding O/R
mapping with CL (at least for the purposes I've been involved with).
Because of the ``impedence mismatch'' you referred to, there's really
a lot of logic that has to be added on top of what LW provides to make
it usable in a largish distributed application (at least, as my
personal experience goes).
There's an excellent chapter on O/R mapping in the book "Enterprise
CORBA", by Slama, Garbis, and Russell. It's nice, because it includes
the final step of distributing these objects and their interfaces.
dave
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m31ypp44k5.fsf@alum.mit.edu>
>>>>> "craig" == Craig Brozefsky <·····@red-bean.com> writes:
>> I looked over USQL, and I think it's impressive, though it's not
>> as complete as what I've personally gotten to work with regarding
>> O/R mapping with CL (at least for the purposes I've been involved
>> with). Because of the ``impedence mismatch'' you referred to,
>> there's really a lot of logic that has to be added on top of what
>> LW provides to make it usable in a largish distributed application
>> (at least, as my personal experience goes).
craig> I would be stoked to learn what logic you need to make USQL
craig> usable in a largish distributed application.
It's been done. I've seen at least one system where LispWorks has
been pushed really hard to have distributed persistent objects with
nice interfaces, and all the transaction handling, slot updating, etc.
It's really quite involved, and I wouldn't argue that it's easy to get
this right. But you can, in fact, have real persistent CLOS objects,
with multiple inheritance, IS-A, HAS-A, and HAS-SOME semantics, as
well as ownership and non-ownership of objects (I don't know if I'm
getting a point across here, but I'm trying). The relationship among
objects programmers generally make use of with transient Lisp objects
far exceed what is obvious in a relational mapping. With such things
considered, the object/relational mapping is a bit more involved, but
the extra work is a big difference. It's been a bit of time for me,
and so I've even forgotten all of the features to make such a system
robust and programming-friendly. All I know is that at the end of the
day, you can write mostly standard CL/CLOS/CommonSQL code, and it's
persistent
>> There's an excellent chapter on O/R mapping in the book
>> "Enterprise CORBA", by Slama, Garbis, and Russell. It's nice,
>> because it includes the final step of distributing these objects
>> and their interfaces.
craig> Is there any free online reference for this topic? I'd hate
craig> to spend bucks on a CORBA book just for one chapter.
wish I could help you there, but sometimes it's worth buying the book
-- especially if this your niche.
dave
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <ey34rup2pzs.fsf@cley.com>
* KURODA Hisao wrote:
> Because there's no DBMS (that serious companies already
> maintain - mostly RDBMS) that allows us to store the data
> types we use usually and naturally.
This is a good point. I work on a system that used to use Oracle (it
now uses a trickle-changes-to-a-log-file approach) to back a
significantly large `database'. There are still a whole load of
places in the system where it prints stuff into a string so it can be
stored in the RDBMS and then later reads it back. It's really
painful.
--tim
<·······@hotmail.com> wrote
> On Sun, 6 May 2001 21:55:20 +0200, "Marc Battyani"
> <·············@fractalconcept.com> wrote:
>
>
> >1) Buy LispWorks. The Enterprise version if you need it. (or ACL or
Corman
> >Lisp according to your taste and/or budget)
> >
> >2) for windows apps : Write the GUI part in Lisp using Win32 API through
> >foreign calls.
> >2bis) for "run everywhere" apps put a (D)HTML interface and use one of
the
> >numerous possibilities to process HTTP requests in Lisp. (from apache
with
> >mod_lisp to CL-HTTP)
>
> What's inherently wrong with:
> 2) Use CAPI or CLIM
Nothing. If CAPI or CLIM fit your needs then use them.
As I do industrial software/hardware, I generally never use anything that is
not standardized or not available as sources, when it's possible.
It has been stated that Lisp is not suitable to do a GUI framework but it's
just totally wrong. Lisp is much more usable than Java or C++.
A few years ago, I've made a cross platform (W32/W16/X/MAC) GUI framework
(now sold to the Sage Group). This was in C++ so not pertinent to this
newsgroup, but I can assure you that making a much more powerful system in
Lisp was really easier (with special thanks to closures and CLOS/MOP).
Marc
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjitjcvuya.fsf@tfeb.org>
David Bakhash <····@localhost.localdomain> writes:
> 2) Corba-enable your application with some IDL interface.
You have a problem. You decide to use CORBA to solve your problem.
Now you have two problems.
> 3) Write the GUI part in Java.
>
Sorry, make that three problems.
--tim (semi seriously)
Tim Bradshaw <···@tfeb.org> writes:
> David Bakhash <····@localhost.localdomain> writes:
>
> > 2) Corba-enable your application with some IDL interface.
>
> You have a problem. You decide to use CORBA to solve your problem.
> Now you have two problems.
>
> > 3) Write the GUI part in Java.
> >
>
> Sorry, make that three problems.
You can always use COM and VC++.
Depressingly yours :{
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > David Bakhash <····@localhost.localdomain> writes:
> >
> > > 2) Corba-enable your application with some IDL interface.
> >
> > You have a problem. You decide to use CORBA to solve your problem.
> > Now you have two problems.
> >
> > > 3) Write the GUI part in Java.
> > >
> >
> > Sorry, make that three problems.
>
> You can always use COM and VC++.
>
> Depressingly yours :{
How many problems do you *then* have? I'm losing track...
Actually, you would have three *large* problems: COM+, C++ and
Visual Studio. There may be others as well.
--
Raymond Wiker
·············@fast.no
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m3y9s72ezb.fsf@alum.mit.edu>
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
tim> David Bakhash <····@localhost.localdomain> writes:
>> 2) Corba-enable your application with some IDL interface.
tim> You have a problem. You decide to use CORBA to solve your problem.
tim> Now you have two problems.
Corba is not a problem; it's a problem solver. It solves the problem
of moving data across the network. It also solves the problem of
managing objects, threads, and persistence.
>> 3) Write the GUI part in Java.
Writing GUIs in Java might be easier. It's not because Java is
better, but because the development environments for writing GUIs in
Java are better, they're cheap, and they allow one to produce nicer
products that (at least in priciple) work everywhere, including
browsers. i.e. this *avoids* the problem of licensing, which is an
issue with several commercial Lisp vendors.
dave
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjheyuwhuu.fsf@tfeb.org>
David Bakhash <·····@alum.mit.edu> writes:
>
> Corba is not a problem; it's a problem solver. It solves the problem
> of moving data across the network. It also solves the problem of
> managing objects, threads, and persistence.
>
It's this kind of answer that bugs me. These things are open problems
which don't *have* general solutions. If corba claims to solve them
it's lying.
But this is what you would expect. Richard Gabriel was wrong: worse
is not better, lying is better. Languages and systems succeed in the
marketplace to the extent that their proponents lie about what they
can do.
Once you realise this you can see it everywhere.
Windows does better than Unix because Windows proponents tell you that
it will solve things that your Unix system people keep telling you are
hard. The Unix people are right: they are hard, and Windows does not
solve them, but by the time you realise that it's too late because it
has you by the throat.
Java does well because Sun told all sorts of lies about what it could
do and exaggerated the rest. C++ does well because people tell at
least two big lies: OOP solves all programming problems and C++ does
OOP.
Virtually any language or system does well because its proponents lie
about other languages - Lisp people know this only too well. GC is
slow, Lisp is an intepreted language - need I go on?
Lisp does badly because we refuse to lie. When people ask us if we
can solve insoluble problems we say that we can't, and because they
expect us to lie to them, they find some other language where the
truth is less respected.
Back to Corba. If it did what you say then building massively
parallel systems would be easy. But it's not easy: in fact no one
knows how to do it at all in general, and those who have written
massively parallel systems will tell you, at length, just how hard it
is.
Don't believe the hype.
--tim
Alright Tim! Say it like it is! I agree with you 100%.
Sure Java might have some nice visual GUI building tools. But they are
useless for doing all but the most basic layouts (especially where the
window changes dynamically based on what is happening). You still have to
code those things by hand.
Wade
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjd79iwc9h.fsf@tfeb.org>
"Wade Humeniuk" <········@cadvision.com> writes:
>
> Sure Java might have some nice visual GUI building tools. But they are
> useless for doing all but the most basic layouts (especially where the
> window changes dynamically based on what is happening). You still have to
> code those things by hand.
I have a theory that if a GUI requires a GUI builder to be usable then
it's failed as a programming interface. I don't know of a GUI toolkit
which has succeeded in this sense.
However I don't understand how this fits in to my lying is better
theory. Programming interfaces seem to gravitate towards a state of
being absurdly overcomplex and yet broken - witness the massive
complexity of something like SMB/CIFS. I think that this happens
because people write small, broken, interfaces, and then lie about
what they can do while ading a huge number of ad-hoc hacks which
eventually let the system do half of what was claimed. Making an
interface huge and obscure also helps in a few ways - it's easy to
learn each little bit, so there's never the kind of fear you might get
with something a little hard, like closures in Lisp; it's also easy to
hide the lies in a huge mass of obscurity; and finally it avoids
having to actually do design while making it look like you are.
--tim
"Tim Bradshaw" <···@tfeb.org> wrote in message
····················@tfeb.org...
> "Wade Humeniuk" <········@cadvision.com> writes:
>
>
> >
> > Sure Java might have some nice visual GUI building tools. But they are
> > useless for doing all but the most basic layouts (especially where the
> > window changes dynamically based on what is happening). You still have
to
> > code those things by hand.
>
> I have a theory that if a GUI requires a GUI builder to be usable then
> it's failed as a programming interface. I don't know of a GUI toolkit
> which has succeeded in this sense.
>
> However I don't understand how this fits in to my lying is better
> theory. Programming interfaces seem to gravitate towards a state of
For a GUI builder to be successful, it has to more powerful than the GUI's
it can build. It has to be more complex, more expressive, more flexible...
The same goes for automated test procedures, the test procedures (code), I
think, has to be more complex than the code it is testing. If you need to
test the test code, well... , you know. The ultimate tester, designer,
coder is the human mind which is more powerful (powerful enough?). The
human mind uses language, mathematics, formal languages to specify
behaviour, in effect, LANGUAGE. Thus I find myself always resorting to a
simple text file writing source code because it is the most expressive.
The real GUI builder is the human mind, tool or no tool. GUI builder's
don't build GUIs, humans build GUIs. Seems to escape some people. Corba is
often referred to as a third party, as if it exists independently of humans.
Corba is a problem solver, no, people are problem solvers. Corba manages
everything, no, even humans cannot manage everything. And just like the GUI
problem, Corba cannot handle all data transfer problems, only people can.
Wade
Tim Bradshaw <···@tfeb.org> writes:
> complexity of something like SMB/CIFS. I think that this happens
> because people write small, broken, interfaces, and then lie about
> what they can do while ading a huge number of ad-hoc hacks which
> eventually let the system do half of what was claimed. Making an
I think there's a _general_ trend in the whole IT world to go for
supercomplex broken solutions instead of usability, and I don't
think it's only a question about lies. I call it "the thing that
goes bing effect" and I think the most depressing example is Microsoft
Office :-(
--
(espen)
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m3d79i57fv.fsf@alum.mit.edu>
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
Your lead in is not substantiated by the development which follows it.
You say:
tim> David Bakhash <·····@alum.mit.edu> writes:
>>
>> Corba is not a problem; it's a problem solver. It solves the problem
>> of moving data across the network. It also solves the problem of
>> managing objects, threads, and persistence.
>>
tim> It's this kind of answer that bugs me. These things are open problems
tim> which don't *have* general solutions. If corba claims to solve them
tim> it's lying.
Then you go on to say:
tim> Windows does better than Unix because Windows proponents tell you that
tim> it will solve things that your Unix system people keep telling you are
tim> hard. The Unix people are right: they are hard, and Windows does not
tim> solve them, but by the time you realise that it's too late because it
tim> has you by the throat.
tim> Java does well because Sun told all sorts of lies about what it could
tim> do and exaggerated the rest. C++ does well because people tell at
tim> least two big lies: OOP solves all programming problems and C++ does
tim> OOP.
Who's talking about lies? Corba is a specification that provides a
solution to particular problems. If you're going to argue that Corba
does not handle the marshaling of structs, strings, integers, floats,
enumerations, etc. across the network, then I will disagree. If you
claim that Corba does not manage references to remote objects and
associations between these references and their implementation
objects, then I will disagree. If you claim that Corba does not
provide a means of sharing resources, then I'll disagree again.
There isn't just one specification of distributed middleware that can
handle some of the issues that arise in modern software development.
There are several, and indeed you see them in the marketplace
(e.g. RMI, Corba, Comm, ILU, EJB, etc.)
I don't think that Corba is a lie. It doesn't magically make your
application distributed. But it does provide a framework for doing
it, and it does help manage and simplify some of the gory details.
I've used it and seen it used. It works. There's no arguing that.
How far you can push it? that's another question. But I doubt that
many people on this newsgroup are really pushing distributed software
technology that hard that Corba is more harm than good.
tim> Virtually any language or system does well because its
tim> proponents lie about other languages - Lisp people know this
tim> only too well. GC is slow, Lisp is an intepreted language -
tim> need I go on?
Lisp *is* slower. Doesn't necessarily mean that it's slow, though.
At least, relatively speaking, it is slower than the rest. It's a
matter of how much, when, and if it matters. On my 1.2 GHz box with a
Gig of ram, it ain't slow at all. :-)
tim> Lisp does badly because we refuse to lie. When people ask us if
tim> we can solve insoluble problems we say that we can't, and
tim> because they expect us to lie to them, they find some other
tim> language where the truth is less respected.
I've solved what I consider to be problems in Lisp that I see other
places hiring armies of programers to do. And I never claimed to be a
great programmer. I'm a decent programmer with kick-ass tools.
It's like a chef having a really sharp knife, very fresh vegetables, a
clean kitchen, good ventilation, extra virgin olive oil. It's not
gonna cook the food, but it sure makes whatever (s)he makes taste
better.
tim> Back to Corba. If it did what you say then building massively
tim> parallel systems would be easy. But it's not easy: in fact no
tim> one knows how to do it at all in general, and those who have
tim> written massively parallel systems will tell you, at length,
tim> just how hard it is.
I never said anything about how well Corba scales. If you want
massive scalability, then you have to do extra work, and Corba
probably doesn't handle these extreme cases too well. Corba does
successfully handle thousands of simultaneous transient objects,
though, and I've tested this recently on my laptop, using a
near-optimal delivery of a LispWorks application.
I'm not claiming that Corba is a godsend. It's a tool that simplifies
part of a design. It doesn't implement a search algorithm for you,
and it won't help you deduce anything. It's just middleware, designed
to help manage large systems that involve several different languages
interoperating. It frees system designers from having to pick a
single language to use for everything in a large, distributed system,
and I'm personally behind it, until something better comes along.
dave
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjoft1xv2z.fsf@tfeb.org>
David Bakhash <·····@alum.mit.edu> writes:
>
> Lisp *is* slower. Doesn't necessarily mean that it's slow, though.
> At least, relatively speaking, it is slower than the rest. It's a
> matter of how much, when, and if it matters. On my 1.2 GHz box with a
> Gig of ram, it ain't slow at all. :-)
>
Thgere, you see, you've believed the hype. Saying that Lisp was slow
would be a lie if it even had any reasonable semantics, which it
doesn't (any more then my sample lie of `GC is slow' doesn't). Lisp
isn't slow, implementations might be, but actually implementations
aren't, applications written in those implementations might be, if you
can even arrive at a definition of `slow' that makes sense. So you
must be, somehow, claiming that all applications written in Lisp are
slower (in some sense that is undefined) than the same applications
written in some other language. Based on what samples? I am aware of
*no* cases where this comparison could reasonably be made.
So what is being done here is taking some huge multidimensional space
of application performance, about which we have almost no data, let
alone reasonable comparative data, and reducing it at a stroke to a
proposed single-dimensional space in some completely undefined way,
and then making a claim about that space.
This is absurd. I realise you're just repeating received wisdom, and
I'm not trying to attack you personally, but you have to realise that
the only reason claims like this (or equivalently `lisp is fast') can
even be *made* is that computer people live in some kind of medieval
mental world.
Although I'm carefully avoiding responding about corba (you see, I
live in the 13th century too!) I think that the claims that are made
about corba - perhaps not by you - are equally absurd, as are those
made about *many* tools and protocols.
--tim
From: Bulent Murtezaoglu
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <87k83pj8hj.fsf@nkapi.internal>
>>>>> "TimB" == Tim Bradshaw <···@tfeb.org> writes:
[... stuff I enjoyed reading and mostly agree with deleted ...]
TimB> ... Saying that Lisp
TimB> was slow would be a lie if it even had any reasonable
TimB> semantics, which it doesn't (any more then my sample lie of
TimB> `GC is slow' doesn't). ...
Here's a link to Henry Baker's CLOStrophobia paper that discusses
inefficiency in CLOS along with a proposal for a remedy. I think
it satisfies your "reasonable semantics" criterion:
http://linux.rice.edu/~rahul/hbaker/CLOStrophobia.html
Far be it from me to claim Common Lisp is slow in general, but I think
points about inefficiencies inherent in CLOS fall into a different
category altogether that the "gc is slow" FUD.
cheers,
BM
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjzockf8xu.fsf@tfeb.org>
Bulent Murtezaoglu <··@acm.org> writes:
>
> Here's a link to Henry Baker's CLOStrophobia paper that discusses
> inefficiency in CLOS along with a proposal for a remedy. I think
> it satisfies your "reasonable semantics" criterion:
>
No it doesn't. Much as I admire Henry Baker, I think it represents
everything that is wrong in this kind of argument. Yes, there are
some now-well-known issues with the way CPLs are computed in CLOS
which can lead to bad performance in some pathological cases. Yes,
CLOS is oriented to a run-time implementation and is resistant to
hairy compile-time analysis. And it's possible to write a nice paper
with a pretty rigorous proof of this.
But is there any evidence that this matters in real life? I haven't
seen any. That's not surprising, because that kind of information is
*really* expensive to come by, while proving little theorems is cheap.
--tim
From: Bulent Murtezaoglu
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <87heyrkjl0.fsf@nkapi.internal>
[... on Baker's CLOStrophobia paper...]
TimB> ... But is there any evidence that this matters in real life? I
TimB> haven't seen any. ...
How's this better evidence than a proof? Well, _I_ have seen some, so
there! Silliness aside, IMHO, people do not complain much about the
performance implications of CLOS's dynamism because:
(1) They put it to good use, so the alternative of rolling their own
would be at least as inefficient and terribly inelegant. The recent
threads here on the use of CLOS illustrate this beautifully. No argument
there.
(2) The kind of efficiency you lose is only relevant if you use
generic functions in tight inner loops. We've learned either not to
use CLOS in such programs or de-CLOSify the code when profiling or
eyeballing reveals bottlenecks. We can show this trivially the next
time someone posts about a performance issue by transforming the
problem to use CLOS. If peppering the code with declarations to, say,
avoid generic arithmetic is worthwhile then CLOS has no place there as
there is no equivalent action you can take to wring performance out of
it. I'd love this not to be the case. Baker points out one solution;
Dylan, as has been pointed out, has a "sealing" facility that serves a
similar end.
(3) Because of the fibbing behaviour of language advocates that you accuse
everyone but lispers of (or maybe just observe, not accuse).
We both dislike this.
My point was simple, I agree with you about the GC or "Lisp is interpreted"
FUD being FUD but since we were being so honest about lisp, I thought I'd
point out some inherent inefficiency and a proposed solution. That's all.
Are we converging or should we just drop it?
cheers,
BM
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <ey38zk12q4q.fsf@cley.com>
* Bulent Murtezaoglu wrote:
> How's this better evidence than a proof? Well, _I_ have seen some, so
> there! Silliness aside, IMHO, people do not complain much about the
> performance implications of CLOS's dynamism because:
It's better than a proof because this kind of proof is entirely
worthless, and anything is better than something worthless.
I think I should give up trying to argue about this because I think
it's hard for people to understand. I'll give an example of what is
wrong with this kind of argument before I give up.
Claim: Caches are useless.
Proof: for any caching scheme I can create a program which will cause
every access to miss the cache. This program will run more slowly
with the cache than it would without, because the memory system is
kept busy filling the cache with useless data all the time.
Similar arguments can be made about memory management systems
(GC-based systems but also malloc/free systems): they all have
dreadful worst cases. And sometimes these cases are actually hit,
too: I've written (accidentally) programs that did bad things to
caches.
So what's wrong with these arguments? They are all nice formal proofs
that algorithm x can have terrible performance. What is wrong with
them is that they ignore the statistics of real programs. Unless you
actually go out and *measure* real programs, running on real data,
then these arguments are worthless.
Another example, somewhat closer to hand, is CLOS accessor
performance. A CLOS accessor is just a method on a GF - you can
define other methods for other classes. So a program that makes use
of accessors may have to do the whole method lookup thing, and as the
CLOStrophobia paper points out, this can be bad. Well, I did some
tests on a particular CLOS implementation - Genera on Ivory processors
- and I found an astonishing thing: in almost all cases accessor
performance was as good as structure accessors. In fact as far as I
could see it was sometimes *faster*! I was amazed. Interestingly,
there were some dreadful worst cases: in particular, if you defined a
non-primary method on an accessor (say an after method to check some
consistency), you lost badly, unless you declared the accessor
notinline. What seems to be happening is that an accessor compiles
into code which does a single-instruction check that it is valid, and
if it is it then fetches the slot, which I think consists of two
lookups - one to find the cached slot position in the instance, and
one to fetch the slot. If the initial validity check turned out to
say that it was not valid, then it punted to code that was pretty slow
- much slower than a generic function call.
And yet we have this proof that CLOS has these horrible problems, so
how come it actually is doing so well? It's doing so well because
someone at Symbolics was smart enough to realise that these bad cases
don't happen very often, and that by caching a lot of information and
making the cache-hit case very fast indeed, while making the
cache-miss case correct.
So here's what I'm trying to say: a proof of a bad worst-case
performance, or a good best-case performance, is only as interesting
in as much as it actually impacts real programs.
In order to know how real programs perform you need to do a *lot* of
rather rigorous experimental work, because you need to compare actual
real systems, not toy examples. I seriously doubt that this kind of
work has been done done very many times for things like language
comparisons: in the cases where people say `for us, language x was
faster than language y' they are almost always comparing a
reimplementation in language x of a program originally written in
language y: that reimplementation is likely to be significantly
different than the original program.
In the CLOStrophobia case, for instance, there is a language - Dylan -
which computes CPLs differently than CL, and I think was designed to
avoid the CLOS pathologies. Do Dylan implementations perform better
than CL ones? Who knows? I suspect that *no valid comparison has
ever been done*, even of these rather similar languages. Why do I
think this? Because doing such a meaningful comparison would cost
tens or hundreds of thousands of pounds (think carefully
reimplementing a significantly large system *without algorithmic
changes or improvements*, and then carefully testing it on real data),
and no one is about to blow that kind of money on a paper on two
relatively obscure languages.
--tim
--tim
From: Bulent Murtezaoglu
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <87elttjg6f.fsf@nkapi.internal>
>>>>> "TimB" == Tim Bradshaw <···@cley.com> writes:
TimB> * Bulent Murtezaoglu wrote:
>> How's this better evidence than a proof? Well, _I_ have seen
>> some, so there! Silliness aside, IMHO, people do not complain
>> much about the performance implications of CLOS's dynamism
>> because:
TimB> It's better than a proof because this kind of proof is
TimB> entirely worthless, and anything is better than something
TimB> worthless.
I don't buy this.
TimB> I think I should give up trying to argue about this because
TimB> I think it's hard for people to understand. I'll give an
TimB> example of what is wrong with this kind of argument before I
TimB> give up.
I think we actually agree when we are talking about the same thing.
You are making a mostly (!) valid point, and if you weren't making it
with a strong language that gives rise to clear-cut counter-examples
it would be easier for people to understand. At least for me, anyway.
TimB> Claim: Caches are useless.
No. This is where we differ. The claim is not that caches are useless,
the claim is caches can cause inefficiency or that they help with specific
access patterns.
TimB> Proof: for any caching scheme I can create a program which
TimB> will cause every access to miss the cache. This program
TimB> will run more slowly with the cache than it would without,
TimB> because the memory system is kept busy filling the cache
TimB> with useless data all the time.
Yes, and having read your proof I am much better off. It is not
unusual to arrange code to make better use of the cache when the
situation warrants it. Your effort that went into the proof may actually
help me understand the issues. I would not call this worthless. Now,
if I were sinking time into optimizing _all_ memory accesses
because I am an idiot and ignore sage advice about premature
optimization, that's another matter and it does not mean your proof was
worthless.
[...]
TimB> So what's wrong with these arguments? They are all nice
TimB> formal proofs that algorithm x can have terrible
TimB> performance. What is wrong with them is that they ignore
TimB> the statistics of real programs. Unless you actually go out
TimB> and *measure* real programs, running on real data, then
TimB> these arguments are worthless.
This is an observation about programmer sanity, I think. If you explain
to me that generic arithmetic is expensive (on regular hardware) and if
I then go sink two days into peppering my code with "the"s and "declare"s
it was not because your explanation was useless, it was because I was
a dolt since I did this without first seeing if generic artihmetic was
hurting me. So yes, I wholeheartedly agree with the measurement point.
[...]
TimB> So here's what I'm trying to say: a proof of a bad
TimB> worst-case performance, or a good best-case performance, is
TimB> only as interesting in as much as it actually impacts real
TimB> programs. [...]
Sure. No argument from me there. I would not call the exercise of
coming of with these proofs worthless though, that's where we seem to
differ. FUD is worthless and can be harmful, honest proofs, when read
properly are not. If the argument is that it is easier to prove
things on paper than collecting evidence from running programs, I
mostly agree there also. Your cache example is actually very apt for
that as memory traces are used to justify design decisions about
caches. So I think the time you sunk into this exchange has not been
worthless!
cheers,
BM
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <ey3zoch11b0.fsf@cley.com>
* Bulent Murtezaoglu wrote:
>>>>>> "TimB" == Tim Bradshaw <···@cley.com> writes:
> Sure. No argument from me there. I would not call the exercise of
> coming of with these proofs worthless though, that's where we seem to
> differ. FUD is worthless and can be harmful, honest proofs, when read
> properly are not. If the argument is that it is easier to prove
> things on paper than collecting evidence from running programs, I
> mostly agree there also. Your cache example is actually very apt for
> that as memory traces are used to justify design decisions about
> caches. So I think the time you sunk into this exchange has not been
> worthless!
That is exactly my point - the CLOStrophobia paper was a paper proof
that there are bad cases in CLOS, when what is needed is performance
traces of a CLOS implementation. If you have those, and if *those*
show something bad, then there's a problem, otherwise there is not,
even if there is a theoretical bad case. This is why I disagreed,
originally with the Lisp is slow claim. I'll shut up now.
--tim
>>>>"TB" == Tim Bradshaw schrieb am 13 May 2001 20:44:35 +0100:
Disclaimer: I haven't read the paper you're arguing about. That said ..
TB> That is exactly my point - the CLOStrophobia paper was a paper
TB> proof that there are bad cases in CLOS, when what is needed is
TB> performance traces of a CLOS implementation.
The first part of your sentence is exactly why it was not
worthless. It is important to know deficiencies, especially if they
are *not* implementation dependent but arise from the language
design.
This kind of knowledge is important and the reason why they are
teaching theoretical computer science courses in which you learn about
such boring things as NP-completeness and reduction of problem $B$ to
some other problem $B$. With such knowledge, you can know *in advance*
that there will not be a general, efficient solution to your problem
$A$ if you can reduce it to $B$.
Similarly, to master a language, it is not only important to know
its constructs, but also their costs and pitfalls.
I maybe walking on thin ice here, but your reactions remind me of that
all wording "Lisp programmers know the value of everything, but the
price of nothing". I'm aware that you're saying that you need to know
*YOUR* concrete costs, but you seem to deny that these actually show
up. You're likely to be a statistician rather than a logician,
probably :-) BTW: due to the paper you at least know where to look for
(some of the possibly) costly cases.
Furthermore, for some of the prominent theoretical hard problems
approximations are known that may help you solve *YOUR* problem $A$. I
hope that the CLOStrophobia-paper also contains some good advice ...
TB> If you have those, and if *those* show something bad, then
TB> there's a problem, otherwise there is not, even if there is a
TB> theoretical bad case. This is why I disagreed, originally with
TB> the Lisp is slow claim. I'll shut up now.
Either I missed several posts or nobody claimed that Lisp was
slow. This is a much more general claim and I would be surprised to
find it explicit or implicit in H. Bakers "CLOStrophobia paper".
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"A difference between computers and cars is that computers usually
do not kill people who will not adapt to them. Some would consider
this a design flaw."
-- Lars Syrstad in gnu.emacs.help
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m366f83v19.fsf@alum.mit.edu>
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
tim> David Bakhash <·····@alum.mit.edu> writes:
>>
>> Lisp *is* slower. Doesn't necessarily mean that it's slow,
>> though. At least, relatively speaking, it is slower than the
>> rest. It's a matter of how much, when, and if it matters. On my
>> 1.2 GHz box with a Gig of ram, it ain't slow at all. :-)
>>
tim> Thgere, you see, you've believed the hype. Saying that Lisp was
tim> slow would be a lie if it even had any reasonable semantics,
tim> which it doesn't (any more then my sample lie of `GC is slow'
tim> doesn't). Lisp isn't slow, implementations might be...
I use *implementations*. I see that there are several ways in which
they're a bit slower. Lisp, as a language, is not inherently slow, of
course. CLISP is certainly slow -- even noticeably, relative to other
Lisps, and even CLISP is very useful to me.
Whatever. This is not a useful discussion. People who like Lisp
should give it a try and see if it meets their needs, and makes the
whole development cycle better.
dave
David Bakhash <····@localhost.localdomain> writes:
> On a wild aside, I don't see why anyone would do the GUI development
> part of any project in Common Lisp, given the existence of Corba and
> Java. It's just not smart design. It's not web-friendly design
> either, since applets can talk Corba, and can work in browsers without
> expensive Lisp stuff on every computer. (of course, with ACL, they
> already figured that in, and charge you for it, making all
> client-server designs almost impossible to pay for themselves).
> Basically, if you want to build a GUI program, then I personally
> recommend:
>
> 1) Buy LispWorks Enterprise: $2,000 (includes Corba, SQL, ODBC, etc.)
> 2) Corba-enable your application with some IDL interface.
> 3) Write the GUI part in Java.
Last year, I made a application using,
0) Bought Allegro Common Lisp,
1) Corba-enabled the application with IDL(ORBLink),
2) Wrote the GUI part in Java Applet.
But I don't think it's happy for us Lisp programmers to use
Corba. It was very annoying for me to Corba-enable a Lisp
application. e.g,
- everytime you change the data schema, you must edit a IDL
file and compile and load it.
- you can't use dynamic typing.
- you can't use data types like rational number.
- once a ORB object exported to world-wide, it must be
garbage collected by the programmer.
To develop the GUI part in Java was more annoying.
Everytime you find the bug, you must edit a Java source file
and compile it and stop the running client program and
re-run it and re-operate it from the start and check it.
Java applet is very easy to freeze, and there's almost no
way for us to know what happend in JavaVM of a browser.
Even though, you can't get information from technical
support.
You also have to struggle with Java's platform dependency
(not independency of course).
Corba's object management and Java's anti-reliability was
the most issue that took our developing time.
> This is the ultimate way to develop *all* applications -- especially
> 3-tier apps. You have a database server, your Lisp for logic, and
> Java for connectivity, portability, and nice GUI tools.
I think the ultimate way to develp applications is write a
whole code in Lisp. So next time I have a chance to write
C/S apps, I'd like to choose,
0) put the server as lisp-binded object-database or the
like.
1) write the client using browser-plugin-able Common Lisp
and CLIM.
--
(define (KURODA Hisao)
(email ······@msi.co.jp))
KURODA Hisao <······@msi.co.jp> writes:
> - everytime you change the data schema, you must edit a IDL
> file and compile and load it.
from what I've heard (and learned, from conferences) from the
corba camp, they're going through nightmares with idl versioning
in large systems. This inflexibility is the reality behind the
components-everywhere religion of the buzzword generators :-(
--
(espen)
On 08 May 2001 20:46:43 +0900, KURODA Hisao <······@msi.co.jp> wrote:
> I think the ultimate way to develp applications is write a
> whole code in Lisp. So next time I have a chance to write
> C/S apps, I'd like to choose,
>
> 0) put the server as lisp-binded object-database or the
> like.
> 1) write the client using browser-plugin-able Common Lisp
> and CLIM.
Maybe you already know this paper:
Adapting CLIM Applications for Use on the WWW
ftp://ftp.ai.sri.com/pub/papers/paley-luv95.ps.Z
Paolo
. This text added to keep my NNTP server happy .
. This text added to keep my NNTP server happy .
. This text added to keep my NNTP server happy .
. This text added to keep my NNTP server happy .
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m33daf3tsn.fsf@alum.mit.edu>
>>>>> "kuroda" == KURODA Hisao <······@msi.co.jp> writes:
kuroda> Last year, I made a application using,
kuroda> 0) Bought Allegro Common Lisp,
kuroda> 1) Corba-enabled the application with IDL(ORBLink),
kuroda> 2) Wrote the GUI part in Java Applet.
kuroda> But I don't think it's happy for us Lisp programmers to use
kuroda> Corba. It was very annoying for me to Corba-enable a Lisp
kuroda> application. e.g,
kuroda> - everytime you change the data schema, you must edit a IDL
kuroda> file and compile and load it.
Does this really bother you? Your defsystem should handle the
recompilation of whatever files need to be recompiled. If there are
dependencies, then so what? IDL is probably the easiest thing in the
world to write. It's not even code; it's just definitions of
interfaces and data structures. And the point of good design is to
design your architecture and interfaces correctly before you start
implementing, so that there are as few changes as possible there. If
this is not the direction in which you design and implement systems,
then you're being grossly inefficient with or without Corba.
kuroda> - you can't use dynamic typing.
I figured out a work-around for this. I usually don't need fully
dynamic typing, so instead I use a simple union whose discriminator
holds one of the possible types of the output.
kuroda> - you can't use data types like rational number.
If you really wanted to, you could work around this too, but I'd say
that most thin client applications don't need this level of
sophistication. Consider that as complex as your database-backed
applications are, they are clients to database servers which basically
return strings.
If you need *any* special structure in your client that's not a basic
type in IDL, then you do what IDL was designed for: define it.
kuroda> - once a ORB object exported to world-wide, it must be
kuroda> garbage collected by the programmer.
I think you're wrong here too. Garbage colloction applies
equivalently to implementation objects (servants) and all Lisp
objects. I havn't felt the need to do any painful garbage collection.
In general, Corba supports eviction policies. In addition, clients
should be designed so that most of the data they have access to on the
server should be through top-level interface objects which can easily
be deactivated when the client no longer needs them. This shouldn't
feel anything as painful as memory management, such as in C++. I
don't think I'd even call it manual garbage collection, if done
right.
kuroda> To develop the GUI part in Java was more annoying. Everytime
kuroda> you find the bug, you must edit a Java source file and
kuroda> compile it and stop the running client program and re-run it
kuroda> and re-operate it from the start and check it. Java applet
kuroda> is very easy to freeze, and there's almost no way for us to
kuroda> know what happend in JavaVM of a browser. Even though, you
kuroda> can't get information from technical support. You also have
kuroda> to struggle with Java's platform dependency (not independency
kuroda> of course).
While the platform independence of Java has always been in question,
and is something that will probably take some time to stabilize, the
``recompilation'' is something you feel, and a good IDE should make
this mostly invisible to you, provided it's aware of the dependecy
hierarchy.
kuroda> Corba's object management and Java's anti-reliability was
kuroda> the most issue that took our developing time.
I believe that if you keep it simple (i.e. don't use all the funkiest
features in Corba and Java), things end up working fine.
>> This is the ultimate way to develop *all* applications -- especially
>> 3-tier apps. You have a database server, your Lisp for logic, and
>> Java for connectivity, portability, and nice GUI tools.
kuroda> I think the ultimate way to develp applications is write a
kuroda> whole code in Lisp. So next time I have a chance to write
kuroda> C/S apps, I'd like to choose,
kuroda> 0) put the server as lisp-binded object-database or the
kuroda> like.
kuroda> 1) write the client using browser-plugin-able Common Lisp
kuroda> and CLIM.
What you're describing is the unrealistic-for-the-present best way.
Recall that your Lisp services are going to be just one of potentially
many services that these clients may need to communicate with.
There are so many subtleties that occur when you try to distribute
objects in an application. I'd hate to have to re-invent that stuff.
Corba handles just about every case I've had to deal with, and, in
addition, the issue of data marshaling, which takes a lot of time when
done manually.
Corba support in Lisp is pretty valuable from both ends, client and
server. It's actually an independent issue whether you want to
actually implement the client in Java, Lisp, or whatever, but for
security, fault-tolerance, and portability, Corba is probably today's
best bet.
dave
David Bakhash <·····@alum.mit.edu> writes:
> kuroda> - everytime you change the data schema, you must edit a IDL
> kuroda> file and compile and load it.
>
> Does this really bother you?
Yes.
Why must I re-compile whole IDL when I change just one
line of it?
Remember, you must also re-compile whole client files which
depends on the changed interface. I couldn't bear it.
> And the point of good design is to
> design your architecture and interfaces correctly before you start
> implementing, so that there are as few changes as possible there.
I don't agree this.
When I start building a system, I design the architecture
and interfaces as loose as possible. Interfaces are also
program code for me. I know this is not a way of text book,
but I think this spiral way is most efficient and make the
system robust.
If Corba is a problem solver, it should bring us dynamic
feature as well as other features. but I think it does not.
> If you need *any* special structure in your client that's not a basic
> type in IDL, then you do what IDL was designed for: define it.
I don't think dynamic typing and rational numbers are
special, it's quite common and natural.
Why must I use union when I just need dynamic typing?
Why must I be bothered by the poor low C-like level of
abstraction?
This is the most point I don't understand about Corba.
> kuroda> - once a ORB object exported to world-wide, it must be
> kuroda> garbage collected by the programmer.
>
> I think you're wrong here too. Garbage colloction applies
> equivalently to implementation objects (servants) and all Lisp
> objects. I havn't felt the need to do any painful garbage collection.
Once ORB object exported with IOR, how can GC(Lisp system)
know when that object is obsolete? Is there a general way?
> In general, Corba supports eviction policies. In addition, clients
> should be designed so that most of the data they have access to on the
> server should be through top-level interface objects which can easily
> be deactivated when the client no longer needs them.
Object deactivation are done by client?
What happens when clients crash or freeze?
Would you explain this more specific?
I still have no idea how should I manage ORB objects in a
server.
> kuroda> 0) put the server as lisp-binded object-database or the
> kuroda> like.
> kuroda> 1) write the client using browser-plugin-able Common Lisp
> kuroda> and CLIM.
>
> What you're describing is the unrealistic-for-the-present best way.
> Recall that your Lisp services are going to be just one of potentially
> many services that these clients may need to communicate with.
Your comment here maybe justify to use Corba,
but there's no reason to use Java right?
Now I think I might use Corba if needed,
but I believe Java is no useful tool to build anything.
thank you.
--
(define (KURODA Hisao)
(email ······@msi.co.jp))
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m366fa56ma.fsf@alum.mit.edu>
>>>>> "kuroda" == KURODA Hisao <······@msi.co.jp> writes:
kuroda> David Bakhash <·····@alum.mit.edu> writes:
kuroda> - everytime you change the data schema, you must edit a IDL
kuroda> file and compile and load it.
>>
>> Does this really bother you?
kuroda> Yes.
kuroda> Why must I re-compile whole IDL when I change just one
kuroda> line of it?
kuroda> Remember, you must also re-compile whole client files which
kuroda> depends on the changed interface. I couldn't bear it.
I know that, at least with LispWorks, compiling IDL files is slow, and
very painful. Luckily, their defsystem thingy prevents it from
happening too often (along with not touching them very often).
>> And the point of good design is to
>> design your architecture and interfaces correctly before you start
>> implementing, so that there are as few changes as possible there.
kuroda> I don't agree this.
kuroda> When I start building a system, I design the architecture
kuroda> and interfaces as loose as possible. Interfaces are also
kuroda> program code for me. I know this is not a way of text book,
kuroda> but I think this spiral way is most efficient and make the
kuroda> system robust.
kuroda> If Corba is a problem solver, it should bring us dynamic
kuroda> feature as well as other features. but I think it does not.
Well, your client must know what's available. If you didn't have
Corba, but instead a protocol interface file, you'd have to at least
put the new functinality in another file, and compile that. If you
want, you can split up your IDL into multiple files as well, though
IDL is structured more lexically, like C++, so I guess that's not
always very easy.
I don't think this is such a big deal, though. If you really couldn't
handle the recompilation aspects of Corba programming, then you could
be a bit smarter about how you organize your IDL files, and at least
some of the pain would disappear.
>> If you need *any* special structure in your client that's not a
>> basic type in IDL, then you do what IDL was designed for: define
>> it.
kuroda> I don't think dynamic typing and rational numbers are
kuroda> special, it's quite common and natural.
kuroda> Why must I use union when I just need dynamic typing?
kuroda> Why must I be bothered by the poor low C-like level of
kuroda> abstraction?
kuroda> This is the most point I don't understand about Corba.
Remeber that the missing features in Corba are part of the price for
interoperability. Many features that Corba does provide make
implementing Corba in particular langauge environments very
difficult. Corba is least common denominator middleware, and so yeah,
it is kinda limited in its type hierarchy. I havn't seen *any*
langauge whose type system compares to Common Lisp, which is why the
IDL mapping into CL datatypes is so simple for Common Lisp. IDL
inheritance and types are a small subset of what is offered by Common
Lisp. So yeah -- if you've first designed your application and then
want to Corba-enable it, I guess it can be frustrating, because you
might have used features in CL that you'd probably want to stay away
from when using Corba (e.g. bignums, rationals, etc.)
kuroda> - once a ORB object exported to world-wide, it must be
kuroda> garbage collected by the programmer.
>>
>> I think you're wrong here too. Garbage colloction applies
>> equivalently to implementation objects (servants) and all Lisp
>> objects. I havn't felt the need to do any painful garbage
>> collection.
kuroda> Once ORB object exported with IOR, how can GC(Lisp system)
kuroda> know when that object is obsolete? Is there a general way?
eviction policies.
kuroda> Object deactivation are done by client?
kuroda> What happens when clients crash or freeze?
kuroda> Would you explain this more specific?
kuroda> I still have no idea how should I manage ORB objects in a
kuroda> server.
again, eviction policies can take care of the non-graceful client
exits.
kuroda> 0) put the server as lisp-binded object-database or the
kuroda> like.
kuroda> 1) write the client using browser-plugin-able Common Lisp
kuroda> and CLIM.
>>
>> What you're describing is the unrealistic-for-the-present best way.
>> Recall that your Lisp services are going to be just one of potentially
>> many services that these clients may need to communicate with.
kuroda> Your comment here maybe justify to use Corba,
kuroda> but there's no reason to use Java right?
I suppose not. Actually, I *only* like Java because:
1) I feel that it will eventually stabilize, because lots of money is
being spent on making it do what has been promised (e.g. platform
independence, browser-independence, relative quickness...)
2) Lots of Java libraries out there
3) Several affordable Java implementations, compilers, IDEs, etc.
kuroda> Now I think I might use Corba if needed,
kuroda> but I believe Java is no useful tool to build anything.
I hope you're wrong about Java. I've got a lot riding on it now. :-)
dave
>>>>> "hk" == KURODA Hisao <······@msi.co.jp> writes:
hk> If Corba is a problem solver, it should bring us dynamic
hk> feature as well as other features. but I think it does not.
to be fair, there are quite a lot of dynamic features in CORBA. The
trading service lets you aquire object references dynamically based on
constraints and preferences. The Interface Repository allows
introspection on interfaces (at a syntactic level). The Dynamic
Invocation Interface allows you to construct queries dynamically: no
static stubs/skeletons.
hk> I don't think dynamic typing and rational numbers are
hk> special, it's quite common and natural.
you're spoilt by too much exposure to Lisp :-)
hk> Why must I use union when I just need dynamic typing?
hk> Why must I be bothered by the poor low C-like level of
hk> abstraction?
hk> This is the most point I don't understand about Corba.
as David said, CORBA supports language interoperability, so there are
constraints. However, you do get better abstraction than in C:
consider exceptions, sequences, Anys.
hk> Once ORB object exported with IOR, how can GC(Lisp system)
hk> know when that object is obsolete? Is there a general way?
The publisher of a persistent IOR has no general way of knowing when
the IOR is no longer useful to anyone. In most designs a client will
tell the server once it has finished with it, but it is true that if a
client crashes, the server will accumulate useless state.
However, you should not confuse a CORBA Object --an entity in the
CORBA object model-- with a servant, which is a programming language
entity which implements a CORBA Object. While in certain cases you may
have a one-to-one mapping between these two entities, more
sophisticated strategies are possible. The servant lifecycle can be
decoupled from that of the CORBA Object, for example using the evictor
pattern mentioned by David, to that a servant may be GCed (after having
saved its state) after a given period of inactivity. You can also have
one servant for multiple CORBA Objects (flyweight pattern).
So while storage management is not as simple as if everything is Lisp
running in a single image, it isn't really difficult. It would be nice
to have leases (as in Jini), but you can always implement them at the
application level.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
On Sun, 6 May 2001 13:03:38 GMT, Kent M Pitman <······@world.std.com>
wrote:
> I'm just watching this discussion from the outside, since I don't
> personally use ILISP, but I have to ask: to what degree is this a
> problem with ILISP and to what degree is it a problem with the
> individual lisps (e.g., LispWorks). That is, does ILISP have some
ILISP does not provide any kind of support for interacting with
multithreaded Lisps. It has no interface for this, so there is no problem
at all with LispWorks--or any other Lisp implementation, for that matter.
It's simply a feature missing from ILISP.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Kent M Pitman
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <sfw4ruxjcq4.fsf@world.std.com>
Paolo Amoroso <·······@mclink.it> writes:
> On Sun, 6 May 2001 13:03:38 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> > I'm just watching this discussion from the outside, since I don't
> > personally use ILISP, but I have to ask: to what degree is this a
> > problem with ILISP and to what degree is it a problem with the
> > individual lisps (e.g., LispWorks). That is, does ILISP have some
>
> ILISP does not provide any kind of support for interacting with
> multithreaded Lisps. It has no interface for this, so there is no problem
> at all with LispWorks--or any other Lisp implementation, for that matter.
> It's simply a feature missing from ILISP.
Thanks for clarifying this. I kept getting the sense from postings
here that some set of people felt the LispWorks ILISP was broken, and
I somehow doubted that.
It does sound like a useful area for the ILISP people to look into
extending. Doesn't sound that hard. (Sounds like most of the hard
stuff would be on the implementation side, but that presumably that
would be work volunteered by vendors in the name of standards adherence
if someone would just spec out a common interface...)
Kent M Pitman <······@world.std.com> writes:
> Thanks for clarifying this. I kept getting the sense from postings
> here that some set of people felt the LispWorks ILISP was broken, and
> I somehow doubted that.
Well, it definitely does not work out-of-the box with LispWorks for
Windows (although disabling the pop-up arglist feature seems to help a
lot).
> It does sound like a useful area for the ILISP people to look into
> extending. Doesn't sound that hard. (Sounds like most of the hard
> stuff would be on the implementation side, but that presumably that
> would be work volunteered by vendors in the name of standards adherence
> if someone would just spec out a common interface...)
FWIW, Lucid shipped the Franz ELI interface with LCL (and renamed all
of the elisp functions and made some gratuitous changes to the default
key bindings while they were at it). Nevertheless, it seemed work a
whole lot better than any of the Emacs interfaces Lucid left for you
in the "goodies" directory.
This package still ships with Liquid Common Lisp and it would be great
if a whole bunch of LispWorks customers could get together and
convince Xanalys to support this in LispWorks (or at least provide the
server-side sources).
From: Bulent Murtezaoglu
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <87n18ok5l7.fsf@nkapi.internal>
>>>>> "KMP" == Kent M Pitman <······@world.std.com> writes:
[...]
KMP> ... (Sounds like most
KMP> of the hard stuff would be on the implementation side, but
KMP> that presumably that would be work volunteered by vendors in
KMP> the name of standards adherence if someone would just spec
KMP> out a common interface...)
Hmm, what springs to my mind is Franz's LEP (Lisp-Emacs-Protocol I
believe).
cheers,
BM
From: David Bakhash
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <m3zocps587.fsf@alum.mit.edu>
>>>>> "ap" == Alain Picard <·······@optushome.com.au> writes:
ap> Forget fancy menus, let's get to work on the basics _first_.
This is my beef with ilisp as well. I actually think that ilisp
should be completely redesigned from scratch. Both ilisp and eli
(Franz) seem bloated and overly complicated for what they do. Maybe
I'm wrong, but certainly ilisp is and has always been broken in many
ways, on many platforms, and for many Lisps. I *should* be able to
run ilisp and have it just work perfectly with LispWorks. But that's
not what happens.
Just to expound on what AP mentioned, it would be nice, for the
multi-threaded Lisps, to have ilisp support the multiple listener
threads.
Though I never got to familiarize myself with it, I have at least seen
a very fancy Lisp interface from XEmacs. It was using Lucid (now
LCL). Printed representations of objects were extents with their own
menus which could be traversed to inspect objects, etc. It was quite
an integration feat. I personally don't need much more than M-x shell
+ LispWorks (or whatever Lisp I'm using), but the integration is nice
to have, just to save you from having to write out some lengthy Lisp
commands to compile and load files, etc.
Maybe the reason that ilisp is so broken is that they try to have it
work for so many different Lisps. That's sad, since the only ones it
*should* work with are LispWorks, ACL, CMUCL, CLISP, Lucid, and
CormanLisp (this last one is currently unsupported, as far as I know).
I don't know, but despite being myself an elisp hacker, I can't get my
ilisp to work right for LispWorks on Linux using XEmacs. I know it's
been done, but I'd just so much rather that the maintainers take the
time to actually try running ilisp + (say) LispWorks in the various
emacsen.
dave
David Bakhash <·····@alum.mit.edu> writes:
> This is my beef with ilisp as well. I actually think that ilisp
> should be completely redesigned from scratch. Both ilisp and eli
> (Franz) seem bloated and overly complicated for what they do. Maybe
> I'm wrong, but certainly ilisp is and has always been broken in many
> ways, on many platforms, and for many Lisps. I *should* be able to
> run ilisp and have it just work perfectly with LispWorks. But
> that's not what happens.
Yes, the secret ingredient for all of this is that you or someone else
contributes the code neccesarry to get it working on the Lisp you are
trying to use.
ILISP relies upon some stuff that is not in the ANSI standard, like
getting argument list, caller lists, interacting with the debugger to
go up and down frames, abort to top-level and so forth.
> Maybe the reason that ilisp is so broken is that they try to have it
> work for so many different Lisps. That's sad, since the only ones
> it *should* work with are LispWorks, ACL, CMUCL, CLISP, Lucid, and
> CormanLisp (this last one is currently unsupported, as far as I
> know). I don't know, but despite being myself an elisp hacker, I
> can't get my ilisp to work right for LispWorks on Linux using
> XEmacs.
What significant cost is there to the maintainers to include the
already submitted code from others supporting those lisps, including
schemes, which are not on your list above? There is a well-defined
interface between the general ILISP code, and the interface for each
Lisp implementation ILISP supports.
> I know it's been done, but I'd just so much rather that the
> maintainers take the time to actually try running ilisp + (say)
> LispWorks in the various emacsen.
You are welcome to do this. You can submit patches if you like.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
David Bakhash <·····@alum.mit.edu> wrote:
: CormanLisp (this last one is currently unsupported, as far as I know).
I patched both (corman and ilisp) last october, but haven't had time now to
check for the latest corman 1.42 fixes, which at least fixed readtables.
ilisp was also pretty unstable then. should be better now. (frames,
popup arglists)
http://xarch.tu-graz.ac.at/autocad/lisp/cormanlisp/
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <ey3wv7su686.fsf@cley.com>
* Jochen Schmidt wrote:
> AFAIK the GTK-XEmacs will also run under Windows! (Using the GTK
> port to windows) Think of popup-menus, Or Tooltips and so on! We
> could e.g use GTK Tooltip to show the arguments of a Function in a
> way often seen in the "Visual" IDEs. We could include
> Process-Browsers, Class-Browser and so on with nice looking GUIs.
Like others I think that ilisp has huge lacunae which need filling
before people spend a lot of time on GUI stuff. These are not just
better Lisp integration, but also issues of general stability and
testing - I have several times backed out ilisp upgrades because they
simply didn't work in our (fairly vanilla) Emacs setup. I also
*really* don't want ilisp to start offering features which would force
me to change to or have to support some yet other emacs variant.
Emacs is a significant bit of infrastructure for many people and
changing it can produce enormous pain.
Note that the comments above are not meant to be critical of the ilisp
maintainers: I realise that they have other jobs and are working on
ilisp unpaid. Ilisp is a lot better than it was 7 or 8 years ago!
--tim
Tim Bradshaw <···@cley.com> writes:
> * Jochen Schmidt wrote:
> > AFAIK the GTK-XEmacs will also run under Windows! (Using the GTK
> > port to windows) Think of popup-menus, Or Tooltips and so on! We
> > could e.g use GTK Tooltip to show the arguments of a Function in a
> > way often seen in the "Visual" IDEs. We could include
> > Process-Browsers, Class-Browser and so on with nice looking GUIs.
>
> Like others I think that ilisp has huge lacunae which need filling
> before people spend a lot of time on GUI stuff. These are not just
> better Lisp integration, but also issues of general stability and
> testing - I have several times backed out ilisp upgrades because they
> simply didn't work in our (fairly vanilla) Emacs setup. I also
> *really* don't want ilisp to start offering features which would force
> me to change to or have to support some yet other emacs variant.
> Emacs is a significant bit of infrastructure for many people and
> changing it can produce enormous pain.
All in all, I agree with this statement. The only thing that we (the
registered developers/maintainers at Sourceforge) try to do right now
is to add small features, fix bugs and update the documentation.
A rewrite of the guts of ILISP would be a good thing. However, I
would not do it without some thinking ahead.
A lot of ILISP predates several improvements that happened in (X)Emacs
and that I myself only heard of.
Moreover remember that, as far as I am concerned, ILISP must:
1 - conform to ANSI CL
2 - cater to all major implementation of ANSI CL (and Scheme)
3 - Work on *both* XEmacs and Emacs.
> Note that the comments above are not meant to be critical of the ilisp
> maintainers: I realise that they have other jobs and are working on
> ilisp unpaid. Ilisp is a lot better than it was 7 or 8 years ago!
Thanks :) (See my signature :) ).
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Tim Bradshaw
Subject: Re: Should ILISP using features of GTK-XEmacs?
Date:
Message-ID: <nkjg0efx354.fsf@tfeb.org>
Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> All in all, I agree with this statement. The only thing that we (the
> registered developers/maintainers at Sourceforge) try to do right now
> is to add small features, fix bugs and update the documentation.
>
> A rewrite of the guts of ILISP would be a good thing. However, I
> would not do it without some thinking ahead.
>
I remember pleading with some of the CMUCL people *not* to use Ilisp
when they were considering moving from hemlock to some GNU emacs-based
interface, because ilisp was *so* flaky and so obviously horrible
inside. It's improved hugely in terms of stability since then, thanks
to some obviously heroic work, but I still think that it would be nice
to redo it, somehow. On the other hand, it's non-trivial work, as you
say, and it does mostly work right now. However, it's annoying to
have to switch interfaces (to eli for ACL, which despite some people
not liking it I find OK once I adjust the key bindings) or editors
(for LW, which I can only really live with because I use LW on Windows
while most of my emacs world lives on Unix) to get a reasonably
tightly-integrated interface.
> A lot of ILISP predates several improvements that happened in (X)Emacs
> and that I myself only heard of.
Yes, you have to remember the context. When ILISP came along the
standard emacs shell mode was not yet comint-based, and I think
supported a single-level of history, and emacs had negligible and very
idiosyncratic X support, unless you used epoch (itself later than
ilisp I think) which had better but even more idiosyncratic X support
and died twice an hour.
> Moreover remember that, as far as I am concerned, ILISP must:
> 1 - conform to ANSI CL
> 2 - cater to all major implementation of ANSI CL (and Scheme)
> 3 - Work on *both* XEmacs and Emacs.
>
It's good to hear this.
--tim
>>>>"JS" == Jochen Schmidt schrieb am Sat, 5 May 2001 23:49:19 +0200:
JS> I've tried the rather young GTK-XEmacs which is a port of the
JS> Xt-Parts of XEmacs to the GTK Toolkit.
JFYI: this port is at best in early beta-stage. Actually, it's
currently so broken that I re-compiled without GTK as of the latest
version (21.4.1, that is).
JS> This is not only for better look because this port includes
JS> EmacsLisp access to a lot of the GTK-Widgets. AFAIK the
JS> GTK-XEmacs will also run under Windows! (Using the GTK port to
JS> windows) Think of popup-menus, Or Tooltips and so on!
There is absolutely no need to wait for the GTK-port to get either of
that. Tooltips are their today in XEmacs, without GTK. Try
ballon-help.
JS> We could e.g use GTK Tooltip to show the arguments of a Function
JS> in a way often seen in the "Visual" IDEs.
For elisp, there is the eldoc-package which always shows the arguments
of a function in the modeline. This should be pretty easy to combine
with ballon-help to get tooltip like hints. This could be the first
place to start for an integration with ilisp (or any lisp-mode).
JS> We could include Process-Browsers, Class-Browser and so on with
JS> nice looking GUIs.
I am really not sure why somebody would want to do that. Ever seen
Hyperbole with OO-Browser at work? And finally, I agree whole-heartly
with all of the other comments on better areas where ilisp needs
improvement.
Just my 2c,
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Du kommen auf Solaris, Du muessen installieren 250 MB GNU Binaries
oder Du leiden grosse Schmerzen, sein Unix aus Steinzeit. *Ugh*"
-- Kristian Koehntopp in de.comp.os.unix.discussion