Is lisp dying, What about AutoLisp?
Dave White
called AutoLisp?
Autodesk has even introduced a Visual Autolisp? Autolisp has proved
invaluable in handling
the type lists that exist in a drawing database for cad. I figure the
experts at lisp might
even know a few more tricks and turns Autodesk hasn't thought of.
Marco Antoniotti
"Dave White" <drw...@gte.net> writes:
Like asking Autodesk to reimplement everything in a real Common Lisp
:)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Paolo Amoroso
already sick of these recurring predictions of Lisp's imminent death.
I'm not an industry insider, but I see no evident sign of decreased
interest toward Lisp. In a different thread I pointed out that two new
companies recently joined the Lisp business. While digging Lisp's grave,
has anybody noticed that new Lisp books continue to be published? Or that
the August issue of DDJ (i.e. Dr. Dobb's Java :-) includes two articles
describing Lisp applications?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Reini Urban
>> Could some of you lisp gurus redirect you attention to Autodesks subset
>> called AutoLisp?
>> Autodesk has even introduced a Visual Autolisp? Autolisp has proved
>> invaluable in handling the type lists that exist in a drawing database for cad.
>> I figure the experts at lisp might
>> even know a few more tricks and turns Autodesk hasn't thought of.
Marco Antoniotti wrote:
>Like asking Autodesk to reimplement everything in a real Common Lisp :)
What is "everything"?
the whole cad engine as genera (which will not happen for sure, C++ is
quite sufficient for them and there is more man power behind) or just
AutoLISP, which recently was reimplemented totally from a 3rd party
developer and then bought. Not a real CL but better than nothing.
VLDEV (the Lisp behind, for developers) is missing, but it might
probably come with the next release. (?)
According the latest news (10% layoff there and in other similar
companies) it will be hard to develop anything THERE, but you (dave or
others) are invited to help by yourself. (and your time and money :)
Several people tried to help them in improving their lisp in the past,
but Adesk wasn't that much interested.
Corman Common Lisp already runs inside ACAD (as in-process dll, but
without acad framework yet),
ACL could be used as well, not as ARX, but from the outside via FFI.
At least one company does this successfully in an commercial app.
But with this approach is then incompatible to all other FFI's. I
implemented my own incompatible FFI as well. Not to speak about higher
stuff: windows, COM, processes.
Several other interesting projects are happening and will be announced
soon.
The whole windows world is flowing, at first the lisp core has to
settle, then the apps can follow.
COM, COM+ or not to COMe? which Object System? which Windows (plain SDK
or more abstract).
Threads, FFI, Persistency, ...
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Marco Antoniotti
rur...@xarch.tu-graz.ac.at (Reini Urban) writes:
> >"Dave White" <drw...@gte.net> writes:
> >> Could some of you lisp gurus redirect you attention to Autodesks subset
> >> called AutoLisp?
> >> Autodesk has even introduced a Visual Autolisp? Autolisp has proved
> >> invaluable in handling the type lists that exist in a drawing database for cad.
> >> I figure the experts at lisp might
> >> even know a few more tricks and turns Autodesk hasn't thought of.
>
> Marco Antoniotti wrote:
> >Like asking Autodesk to reimplement everything in a real Common Lisp :)
>
> What is "everything"?
The whole thing :)
Was I sounding too serious? :)
...
> The whole windows world is flowing, at first the lisp core has to
> settle, then the apps can follow.
> COM, COM+ or not to COMe?
CORBA
> which Object System?
Now, *you* must be kidding. I thought this was settled in 1989.
Reini Urban
>> The whole windows world is flowing, at first the lisp core has to
>> settle, then the apps can follow.
>> COM, COM+ or not to COMe?
>CORBA
not CORBA! worse is better.
the evil empire is watching and we have to follow. ActiveX is the way to
go for us.
>> which Object System?
>Now, *you* must be kidding. I thought this was settled in 1989.
only for CL. no, really! this IS an issue.
look at scheme.
One current implementation is right now struggling with this :)
Personally I'd vote for the full CLOS, but just for compatibility's
sake. But others Kiczales' Tiny-CLOS, Meroon (brrh), KR (Garnet's), and
others (the one from MzScheme or private ones) would be also suitable.
--
Reini
Marco Antoniotti
> Marco Antoniotti wrote:
> >> The whole windows world is flowing, at first the lisp core has to
> >> settle, then the apps can follow.
> >> COM, COM+ or not to COMe?
> >CORBA
>
> not CORBA! worse is better.
> the evil empire is watching and we have to follow. ActiveX is the way to
> go for us.
You are right. Worse is better. We had ILU nad now we maybe have to
move to CORBA. The difference being that CORBA is an open standard
(although more or less proprietary). You know what ActiveX is.
> >> which Object System?
> >Now, *you* must be kidding. I thought this was settled in 1989.
>
> only for CL. no, really! this IS an issue.
> look at scheme.
Scheme does not have a DEFSTRUCT yet! Come on, why re-inventing the
wheel all over again and again. Not only re-invent. But re-invent
the wheel in CL-incompatible ways seems to be the name of the game
when it could be easily done otherwise seems to be the name of the
game.
> One current implementation is right now struggling with this :)
> Personally I'd vote for the full CLOS, but just for compatibility's
> sake. But others Kiczales' Tiny-CLOS, Meroon (brrh), KR (Garnet's), and
> others (the one from MzScheme or private ones) would be also suitable.
No they wouldn't. Only Kiczales' Tiny-CLOS could fit the bill. Note
that I am not making any technical comment here. I am just saying
that CLOS is "good enough" and that writing something different would
not be a wise thing.
Harold Carr
> rur...@xarch.tu-graz.ac.at (Reini Urban) writes:
>
> > Marco Antoniotti wrote:
> > >> The whole windows world is flowing, at first the lisp core has to
> > >> settle, then the apps can follow.
> > >> COM, COM+ or not to COMe?
> > >CORBA
> >
> > not CORBA! worse is better.
> > the evil empire is watching and we have to follow. ActiveX is the way to
> > go for us.
>
> You are right. Worse is better. We had ILU nad now we maybe have to
> move to CORBA. The difference being that CORBA is an open standard
> (although more or less proprietary). You know what ActiveX is.
>
CORBA is an open SPECIFICATION. Various vendors have proprietary
implementations of that standard. To me it is an easy decision: if
you are a windows only shop then go with COM. For other platforms
CORBA is the only viable alternative. Plus you can still talk to
COM from CORBA via bridges.
Cheers,
Harold Carr
ex-Autodesk Visual Lisp Lead
current - SUN CORBA guy
Marco Antoniotti
Harold Carr <harol...@eng.sun.com> writes:
> Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> > rur...@xarch.tu-graz.ac.at (Reini Urban) writes:
> >
> > > Marco Antoniotti wrote:
> > > >> The whole windows world is flowing, at first the lisp core has to
> > > >> settle, then the apps can follow.
> > > >> COM, COM+ or not to COMe?
> > > >CORBA
> > >
> > > not CORBA! worse is better.
> > > the evil empire is watching and we have to follow. ActiveX is the way to
> > > go for us.
> >
> > You are right. Worse is better. We had ILU nad now we maybe have to
> > move to CORBA. The difference being that CORBA is an open standard
> > (although more or less proprietary). You know what ActiveX is.
> >
>
> CORBA is an open SPECIFICATION.
Beats COM, doesn't it?
> Various vendors have proprietary
> implementations of that standard.
Obvious.
> To me it is an easy decision: if
> you are a windows only shop then go with COM. For other platforms
> CORBA is the only viable alternative. Plus you can still talk to
> COM from CORBA via bridges.
I never advocated not doing COM. I am saying that you can argue that
it is better to do CORBA, even when you are a Windows only shop.
Espen Vestre
> you are a windows only shop then go with COM. For other platforms
> CORBA is the only viable alternative. Plus you can still talk to
> COM from CORBA via bridges.
I still prefer to roll my own protocols, because:
- OMG seems to redesign the CORBA spec constantly, which weakens
the point that it's an open standard.
- IDL is unecessary and annoyingly rigid for lisp server applications
(i prefer to heavily use keyword-based arglists, which ensures
very good backward compatilility of the protocols).
- As soon as you have implemented a little SEXP parser/printer
in other languages, it isn't really very difficult to implement
your own SEXP-based tcp protocols, and provide API libraries in a
variety of languages.
Since the question of standardizing on corba is an ever returning
one also where I work, I'd be glad to here your opinions or stories
from real life on this matter!
--
(espen)
Philip Lijnzaad
> Harold Carr <harol...@eng.sun.com> writes:
>> you are a windows only shop then go with COM. For other platforms
>> CORBA is the only viable alternative. Plus you can still talk to
>> COM from CORBA via bridges.
> I still prefer to roll my own protocols, because:
> - OMG seems to redesign the CORBA spec constantly, which weakens
> the point that it's an open standard.
not at all: everything in CORBA 2.0 still works in CORBA 2.3; I know of no
incompatibilities.
> - IDL is unecessary and annoyingly rigid for lisp server applications
yes, but IDL is designed^H^H^H^H^H^H^H^Hintended to be mappable to many
different languages, including the majority that doesn't have keyword
arguments. So if you require this interoperability, you're stuck one way or
the other.
> (i prefer to heavily use keyword-based arglists, which ensures
> very good backward compatilility of the protocols).
I imagine you can have some nifty macros transform your idiom into something
that is expected by the emerging OMG Lisp language mapping.
> - As soon as you have implemented a little SEXP parser/printer
> in other languages, it isn't really very difficult to implement
> your own SEXP-based tcp protocols, and provide API libraries in a
> variety of languages.
Not even for strictly in-house client/server stuff. It'd be foolish to
reinvent and reimplement everything using sockets (including location
forwarding, automatic activation, protocol negotiation). I don't think the
avoidance non-keyword function calls (if that's your main objection) would be
worth it.
Philip
--
The cause of the millenium bug is Homo Sapiens having 10 fingers
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Espen Vestre
> > - OMG seems to redesign the CORBA spec constantly, which weakens
> > the point that it's an open standard.
>
> not at all: everything in CORBA 2.0 still works in CORBA 2.3; I know of no
> incompatibilities.
I don't know much of corba yet, but I did actually go to a Corba talk
at the Object Expo Europe in London last year, and the _whole_ talk
was really about how your corba code can survive when everything
changes all the time (I was _very_ dissapointed, from the title
of the talk I expected to get some insight in how systems can be
designed with corba, not a 'corba hacker survival guide')
> Not even for strictly in-house client/server stuff. It'd be foolish to
> reinvent and reimplement everything using sockets (including location
> forwarding, automatic activation, protocol negotiation). I don't think the
> avoidance non-keyword function calls (if that's your main objection) would be
> worth it.
It's a question of how fancy you want your protocol to be. I decided
on a very simple protocol which was easy to implement, and have used
many variants of that protocol since then (once I had the generic stuff
settled, I don't care about the socket level anymore).
I know pretty much for sure that if I'd used Corba, we'd have a much
larger maintainance problem, and probably spent _more_ time than
we did, but I don't expect our simple-minded approach to be useful
for _any_ application.
And we're still considering offering a corba interface for
higher interoperability (or political/tactical :-)) reasons.
Thinking of it, my prejudices against Corba are similar to those
against some wysiwig word processors: They're unecessary complicated
and heavy for the easy tasks they're really used for, and when
you try to use it for a _complicated_ task, it's not general enough
(and gives you version headaches :-)). (and in the end you're
forced to use it anyway, because everybody else think everybody
else is using it!)
> The cause of the millenium bug is Homo Sapiens having 10 fingers
No, it's Marco Polo's fault. He should have brought the Chinese
Calendar to Europe ;-)
--
(espen)
Erik Naggum
| - As soon as you have implemented a little SEXP parser/printer
| in other languages, it isn't really very difficult to implement
| your own SEXP-based tcp protocols, and provide API libraries in a
| variety of languages.
I did this with my client and published the code with the spec to the
customers. they all used it or recoded the design into their own
language, which uses vectors of strings where the first character is a
type code. and fortunately, this means we don't have to deal with
clients written in perl, anymore.
| Since the question of standardizing on corba is an ever returning one
| also where I work, I'd be glad to here your opinions or stories from
| real life on this matter!
I have looked at CORBA and found it to be extremely hard to use for the
needs my client has: a distribution hub for a number of services and a
lot of clients, consisting of a master which talks to any number of
satellite slaves. since we use dedicated links, we also ran into the
data transfer overhead with CORBA. my current overhead is at 3%, and
CORBA seems to add 10% overhead, but this is a pretty weak estimate.
#:Erik
--
it's election time in Norway. explains everything, doesn't it?