[munich-lisp] Next Munich Lispers Meeting
Hi everyone, Thanks for attending yesterday's Munich-lispers meeting. And thanks Tobias for a very insightful and entertaining presentation about SLIME. May I suggest that we have another meeting at the end of January. I've posted onto the wiki http://wiki.alu.org/Munich Anyone can update it who wants to. I've also proposed an agenda. Several people yesterday said they might be interested in knowing about how Lisp is used in EDA, Electronic Design Automation. I'll be happy to show some of the interesting features of SKILL (a lisp dialect) which I use at my job. SKILL, an uncommon lisp * Some cool features * Similarities and differences from CL * Common Lisp-like extensions to SKILL * A very opinionated and probably objectionable view of CLOS (I think it should be). May I suggest we meet on 27 January at 19h00? The same location would be great, if we can reserve the room again. Anyone in favor? -jim -- +------------------------------------------------------------------------+ | Jim E. Newton (jimka@cadence.com) desk +49-(0)89-4563-1918 | | Methodology Services Europe fax +49-(0)89-4563-1819 | | Cadence Design Systems GmbH Munich Germany | | | | If you won't do it in the rain, you won't do it. | +------------------------------------------------------------------------+
Hi, Yesterdays meeting was great, I'd be happy if we could continue on a regular, maybe montly basis. On Thu, 4 Dec 2008 14:43:35 +0100 Jim Newton <jimka@rdrop.com> wrote:
May I suggest that we have another meeting at the end of January. I've posted onto the wiki http://wiki.alu.org/Munich Anyone can update it who wants to.
I think reviving the Wiki page is a good idea to show that the group is still active.
I'll be happy to show some of the interesting features of SKILL (a lisp dialect) which I use at my job.
Great idea, looking forward to it.
May I suggest we meet on 27 January at 19h00?
Sounds good. Maybe even a bit sooner, because yesterday I had to leave earlier to catch my S-Bahn. regards, Marek
2008/12/4 Jim Newton <jimka@rdrop.com>
Hi everyone, Thanks for attending yesterday's Munich-lispers meeting. And thanks Tobias for a very insightful and entertaining presentation about SLIME.
I'll second that.
May I suggest that we have another meeting at the end of January. I've posted onto the wiki http://wiki.alu.org/Munich Anyone can update it who wants to.
I've also proposed an agenda. Several people yesterday said they might be interested in knowing about how Lisp is used in EDA, Electronic Design Automation. I'll be happy to show some of the interesting features of SKILL (a lisp dialect) which I use at my job.
SKILL, an uncommon lisp
* Some cool features * Similarities and differences from CL * Common Lisp-like extensions to SKILL * A very opinionated and probably objectionable view of CLOS (I think it should be).
May I suggest we meet on 27 January at 19h00? The same location would be great, if we can reserve the room again.
Anyone in favor?
Definitely. Well done for taking the initiative. -- Geoffrey Teale Freelance Software and Technology Consultant Munich, Germany
jimka wrote @ Thu, 4 Dec 2008 14:43:35 +0100:
I've also proposed an agenda. Several people yesterday said they might be interested in knowing about how Lisp is used in EDA, Electronic Design Automation. I'll be happy to show some of the interesting features of SKILL (a lisp dialect) which I use at my job.
That would be great.
SKILL, an uncommon lisp
* Some cool features * Similarities and differences from CL * Common Lisp-like extensions to SKILL * A very opinionated and probably objectionable view of CLOS (I think it should be).
A CLOS discussion would be nice to have. I remember some other people mentioning they've never come around to dive into it. I'm a bit uncertain about your stance (some native speaker connotaions might have been lost), are you pro or con CLOS? Can someone else defend the other position?
May I suggest we meet on 27 January at 19h00? The same location would be great, if we can reserve the room again.
After 18:00 the room is basically always available. A better room would be easier to get after 7th of February (semester ends then). Of course the rather warm climate of Z11 (named Takla-Makan) makes it all more chummy, and I wouldn't want to take that away from anyone. -- Andy
On Thursday 04 December 2008 21:46:37 Andreas Hauser wrote:
jimka wrote @ Thu, 4 Dec 2008 14:43:35 +0100:
* A very opinionated and probably objectionable view of CLOS (the way I think it should be).
A CLOS discussion would be nice to have. I remember some other people mentioning they've never come around to dive into it. I'm a bit uncertain about your stance (some native speaker connotaions might have been lost), are you pro or con CLOS? Can someone else defend the other position?
Yes, i'm basically Pro-clos. However, i do no know a lot about theoretically sound object models, and cannot answer questions about CLOS in that regard. I look at CLOS as a tool box of lots of capabilities that just very often come in extremely handy. There are, however, some design decisions which went into its original design (usually for performance reasons) which I think are unfortunate and others which I think are obtuse. One thing that I think is interesting about CLOS is its ability to do what I call Specialization Oriented Programming. I.e., using CLOS not for its object model (where classes represent state laden objects with similar characteristics), but rather using the method dispatch protocol for control flow purposes. In this approach objects of a class do not represent entities in any describable sense, but rather they act as policies to control which methods are applicable and in which order they are evaluated. I suspect many people will disagree with my opinion. I look forward to the discussion -jim
Thanks for putting me in cc, but since I didn't see the beginning of the discussion, I cannot comment on it that well... ;) Pascal On 10 Dec 2008, at 01:12, Jim Newton wrote:
On Thursday 04 December 2008 21:46:37 Andreas Hauser wrote:
jimka wrote @ Thu, 4 Dec 2008 14:43:35 +0100:
* A very opinionated and probably objectionable view of CLOS (the way I think it should be).
A CLOS discussion would be nice to have. I remember some other people mentioning they've never come around to dive into it. I'm a bit uncertain about your stance (some native speaker connotaions might have been lost), are you pro or con CLOS? Can someone else defend the other position?
Yes, i'm basically Pro-clos. However, i do no know a lot about theoretically sound object models, and cannot answer questions about CLOS in that regard. I look at CLOS as a tool box of lots of capabilities that just very often come in extremely handy. There are, however, some design decisions which went into its original design (usually for performance reasons) which I think are unfortunate and others which I think are obtuse.
One thing that I think is interesting about CLOS is its ability to do what I call Specialization Oriented Programming. I.e., using CLOS not for its object model (where classes represent state laden objects with similar characteristics), but rather using the method dispatch protocol for control flow purposes. In this approach objects of a class do not represent entities in any describable sense, but rather they act as policies to control which methods are applicable and in which order they are evaluated.
I suspect many people will disagree with my opinion.
I look forward to the discussion -jim
-- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium
Pascal Costanza <pc@p-cos.net> writes:
Thanks for putting me in cc, but since I didn't see the beginning of the discussion, I cannot comment on it that well... ;)
How about giving Munich a visit at the end of january? :-) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner
participants (6)
-
Andreas Hauser -
Geoffrey Teale -
Jim Newton -
Marek Kubica -
Pascal Costanza -
Tobias C. Rittweiler