I just wrote my own MOP extension to CLOS which maps OO to Entity
Relationsship. One of my whole systems goals is avoiding duplicate work.
Paul Graham is utterly against OO at all. In his assay
http://paulgraham.com/noop.html
he says for example: "Object-oriented programming is exciting if you have a
statically-typed language without lexical closures or macros. To some
degree, it offers a way around these limitations."
Although I do not think he is wrong, I have no idea how I could replace my
own system. I am interested in new ideas.
Can somebody give me a more explanatory hint on alternatives than just
mentioning closures and macros?
What reading can make me agree to PG?
Andreas
On Mon, 6 Jun 2005 11:43:16 +0200, "Andreas Thiele"
<······@nospam.com> wrote:
>I just wrote my own MOP extension to CLOS which maps OO to Entity
>Relationsship. One of my whole systems goals is avoiding duplicate work.
>
>Paul Graham is utterly against OO at all. In his assay
>
>http://paulgraham.com/noop.html
His opinion is pure nonsense:
"I personally have never needed object-oriented abstractions. Common
Lisp has an enormously powerful object system and I've never used it
once. I've done a lot of things (e.g. making hash tables full of
closures) that would have required object-oriented techniques to do
in wimpier languages, but I have never had to use CLOS..."
A.L.
"A.L." <·················@hotfuck.com> schrieb im Newsbeitrag
·······································@4ax.com...
> On Mon, 6 Jun 2005 11:43:16 +0200, "Andreas Thiele"
> <······@nospam.com> wrote:
>
> >I just wrote my own MOP extension to CLOS which maps OO to Entity
> >Relationsship. One of my whole systems goals is avoiding duplicate work.
> >
> >Paul Graham is utterly against OO at all. In his assay
> >
> >http://paulgraham.com/noop.html
>
> His opinion is pure nonsense:
>
> "I personally have never needed object-oriented abstractions. Common
> Lisp has an enormously powerful object system and I've never used it
> once. I've done a lot of things (e.g. making hash tables full of
> closures) that would have required object-oriented techniques to do
> in wimpier languages, but I have never had to use CLOS..."
>
> A.L.
I am not sure :)
I mean obviously he wrote a huge and _succesful_ application.
Using a property list containing some functions/closures/lambdas like
(setf object '(medthod-x (lambda ... ) method-y ... ))
and using (funcall (getf object method-x) ...) we already have something
equivalent to a simple object with polymorphism.
Perhaps one should consider his references
http://paulgraham.com/reesoo.html
and
http://mumble.net/~jar/articles/oo.html
as well.
Andreas
P.S. I find it more interesting to understand his point of view than judging
if he is wrong or right.
On Mon, 6 Jun 2005 13:47:23 +0200, <······@nospam.com> wrote:
> "A.L." <·················@hotfuck.com> schrieb im Newsbeitrag
> ·······································@4ax.com...
>> On Mon, 6 Jun 2005 11:43:16 +0200, "Andreas Thiele"
>> <······@nospam.com> wrote:
>>
>> >Paul Graham is utterly against OO at all. In his assay
>> >
>> His opinion is pure nonsense:
>>
> I am not sure :)
>
> I mean obviously he wrote a huge and _succesful_ application.
Clearly there are also huge and successful CLOS applications....
If I am completely right-hand dominant, should I cut off my left hand
as 'useless' ? Now if you can claim that PG wrote over a dozen huge
and successful applications covering far more than a mere web store, I
might consider that 'OO is <insert preferred negative connotation
here>' has some general validity.
--
With sufficient thrust, pigs fly fine.
"GP lisper" <········@CloudDancer.com> schrieb im Newsbeitrag
················································@teranews...
> On Mon, 6 Jun 2005 13:47:23 +0200, <······@nospam.com> wrote:
> > "A.L." <·················@hotfuck.com> schrieb im Newsbeitrag
> > ·······································@4ax.com...
> >> On Mon, 6 Jun 2005 11:43:16 +0200, "Andreas Thiele"
> >> <······@nospam.com> wrote:
> >>
> >> >Paul Graham is utterly against OO at all. In his assay
> >> >
> >> His opinion is pure nonsense:
> >>
> > I am not sure :)
> >
> > I mean obviously he wrote a huge and _succesful_ application.
>
>
> Clearly there are also huge and successful CLOS applications....
>
>
> If I am completely right-hand dominant, should I cut off my left hand
> as 'useless' ? Now if you can claim that PG wrote over a dozen huge
> and successful applications covering far more than a mere web store, I
> might consider that 'OO is <insert preferred negative connotation
> here>' has some general validity.
>
> --
> With sufficient thrust, pigs fly fine.
Sorry, I didn't want to start a flame war. I didn't ask if he is wrong or
right. I just asked for alternatives.
I must admit that I'm a little impressed by his rejection.
Let me mention that my own application heavyly relies on CLOS and MOP. I
cannot think of rewriting my own app without re-inventing OO and CLOS.
But I'd like to think about an alternative approach or get an idea about it.
Andreas
"Andreas Thiele" <······@nospam.com> writes:
> Let me mention that my own application heavyly relies on CLOS and MOP. I
> cannot think of rewriting my own app without re-inventing OO and CLOS.
That must be a corolary to Greenspun's Tenth Law:
Any sufficiently complicated Common Lisp program that tries to avoid
using parts of Common Lisp will contains an ad-hoc,
informally-specified, bug-ridden, slow re-implementation of the other
half of Common Lisp it did not want to use in the first place.
> But I'd like to think about an alternative approach or get an idea about it.
I doubt there's any alternative approach. OO doesn't means anything
because it's just what programmers have been doing from day 1: manage
complexity using the divide and conquer. The only question is how you
cut the beast. Some prefer little bits, others thick pieces; some
prefer cubes, others slices. If you're unhappy for having sliced your
application horizontally, try vertically. But it most probably wont
be worth the work.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
"Pascal Bourguignon" <···@informatimago.com> schrieb im Newsbeitrag
···················@thalassa.informatimago.com...
> "Andreas Thiele" <······@nospam.com> writes:
> > Let me mention that my own application heavyly relies on CLOS and MOP. I
> > cannot think of rewriting my own app without re-inventing OO and CLOS.
>
> That must be a corolary to Greenspun's Tenth Law:
>
> Any sufficiently complicated Common Lisp program that tries to avoid
> using parts of Common Lisp will contains an ad-hoc,
> informally-specified, bug-ridden, slow re-implementation of the other
> half of Common Lisp it did not want to use in the first place.
>
This is exactly why I decided to go the CLOS way :)
>
> > But I'd like to think about an alternative approach or get an idea about
it.
>
> I doubt there's any alternative approach. OO doesn't means anything
> because it's just what programmers have been doing from day 1: manage
> complexity using the divide and conquer. The only question is how you
> cut the beast. Some prefer little bits, others thick pieces; some
> prefer cubes, others slices. If you're unhappy for having sliced your
> application horizontally, try vertically. But it most probably wont
> be worth the work.
>
Well actually I am happy and don't need redesign. It is more a mental
experiment. How could an alternativ look like? Did I overlook a simple
solution? Would I really need to write something similar to CLOS? I believe
yes.
But it seems only PG can explain how to attack huge problems without any OO
;)
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Until real software engineering is developed, the next best practice
> is to develop with a dynamic system that has extreme late binding in
> all aspects. The first system to really do this in an important way
> is Lisp. -- Alan Kay
Andreas Thiele wrote:
>>Any sufficiently complicated Common Lisp program that tries to avoid
>>using parts of Common Lisp will contains an ad-hoc,
>>informally-specified, bug-ridden, slow re-implementation of the other
>>half of Common Lisp it did not want to use in the first place.
>
>
> This is exactly why I decided to go the CLOS way :)
I sometimes wish parts of Common Lisp itself had gone the CLOS
way. It would be nice if (for example) sequence functions were
actually generic. This needn't be any less efficient on standard
sequences than current implementations (basically, where the current
implementation would signal an error, the generic version would
first look for user-defined methods.)
Paul
Paul F. Dietz wrote:
> Andreas Thiele wrote:
>
>>> Any sufficiently complicated Common Lisp program that tries to avoid
>>> using parts of Common Lisp will contains an ad-hoc,
>>> informally-specified, bug-ridden, slow re-implementation of the other
>>> half of Common Lisp it did not want to use in the first place.
>>
>> This is exactly why I decided to go the CLOS way :)
>
> I sometimes wish parts of Common Lisp itself had gone the CLOS
> way. It would be nice if (for example) sequence functions were
> actually generic. This needn't be any less efficient on standard
> sequences than current implementations (basically, where the current
> implementation would signal an error, the generic version would
> first look for user-defined methods.)
This reminds me, is there some reason that CLRFIs never got anywhere?
This is such a simple thing to implement, that I'm sure that everyone
has their own implementation. It'd sure be nice to have a standard
package for this.
-- MJF
M Jared Finder wrote:
> Paul F. Dietz wrote:
> > I sometimes wish parts of Common Lisp itself had gone the CLOS
> > way. It would be nice if (for example) sequence functions were
> > actually generic. This needn't be any less efficient on standard
> > sequences than current implementations (basically, where the current
> > implementation would signal an error, the generic version would
> > first look for user-defined methods.)
>
> This reminds me, is there some reason that CLRFIs never got anywhere?
> This is such a simple thing to implement, that I'm sure that everyone
> has their own implementation. It'd sure be nice to have a standard
> package for this.
I spoke with Nick Levine about it in late April, and got the impression
that they didn't have time and were momentarily dropping CLRFIs that
were submitted. Probably due to the ALU convention, and they may get
that post-convention motivational bounce to work on this stuff.
Unfortunately, they apparently do not have a viewable archive of all
submissions. Therefore it seems wise to post them in a public wiki or
website before emailing clrfi-editors.
Tayssir
Tayssir John Gabbour wrote:
> M Jared Finder wrote:
>
>>Paul F. Dietz wrote:
>>
>>>I sometimes wish parts of Common Lisp itself had gone the CLOS
>>>way. It would be nice if (for example) sequence functions were
>>>actually generic. This needn't be any less efficient on standard
>>>sequences than current implementations (basically, where the current
>>>implementation would signal an error, the generic version would
>>>first look for user-defined methods.)
>>
>>This reminds me, is there some reason that CLRFIs never got anywhere?
>>This is such a simple thing to implement, that I'm sure that everyone
>>has their own implementation. It'd sure be nice to have a standard
>>package for this.
>
>
> I spoke with Nick Levine about it in late April, and got the impression
> that they didn't have time and were momentarily dropping CLRFIs that
> were submitted. Probably due to the ALU convention, and they may get
> that post-convention motivational bounce to work on this stuff.
>
> Unfortunately, they apparently do not have a viewable archive of all
> submissions. Therefore it seems wise to post them in a public wiki or
> website before emailing clrfi-editors.
Well, the situation is pretty much that. From the technical viewpoint,
there is the problem of having some infrastructure built. A Wiki is
somewhat ok, but maybe we should look at somthing like livejournal or
what MySQL has.
From the "procedural" viewpoint, there are unsolved problems about
voting, editors, and appeals.
Hopefully we can get restarted at ILC.
Cheers
--
Marco
Marco Antoniotti wrote:
> Tayssir John Gabbour wrote:
> > M Jared Finder wrote:
> >>Paul F. Dietz wrote:
> >>>I sometimes wish parts of Common Lisp itself had gone the CLOS
> >>>way. It would be nice if (for example) sequence functions were
> >>>actually generic. This needn't be any less efficient on standard
> >>>sequences than current implementations (basically, where the current
> >>>implementation would signal an error, the generic version would
> >>>first look for user-defined methods.)
> >>
> >>This reminds me, is there some reason that CLRFIs never got anywhere?
> >>This is such a simple thing to implement, that I'm sure that everyone
> >>has their own implementation. It'd sure be nice to have a standard
> >>package for this.
> >
> > I spoke with Nick Levine about it in late April, and got the impression
> > that they didn't have time and were momentarily dropping CLRFIs that
> > were submitted. Probably due to the ALU convention, and they may get
> > that post-convention motivational bounce to work on this stuff.
> >
> > Unfortunately, they apparently do not have a viewable archive of all
> > submissions. Therefore it seems wise to post them in a public wiki or
> > website before emailing clrfi-editors.
>
> Well, the situation is pretty much that. From the technical viewpoint,
> there is the problem of having some infrastructure built. A Wiki is
> somewhat ok, but maybe we should look at somthing like livejournal or
> what MySQL has.
I imagine clicking the button to make ·············@... archives
viewable would suffice. At least for new messages.
A seemingly robust, reliable solution which takes ten seconds to
implement; unless there is something I misunderstand.
Tayssir
> From the "procedural" viewpoint, there are unsolved problems about
> voting, editors, and appeals.
>
> Hopefully we can get restarted at ILC.
Tayssir John Gabbour wrote:
> M Jared Finder wrote:
>>Paul F. Dietz wrote:
>>
>>>I sometimes wish parts of Common Lisp itself had gone the CLOS
>>>way. It would be nice if (for example) sequence functions were
>>>actually generic. This needn't be any less efficient on standard
>>>sequences than current implementations (basically, where the current
>>>implementation would signal an error, the generic version would
>>>first look for user-defined methods.)
>>
>>This reminds me, is there some reason that CLRFIs never got anywhere?
>>This is such a simple thing to implement, that I'm sure that everyone
>>has their own implementation. It'd sure be nice to have a standard
>>package for this.
>
> I spoke with Nick Levine about it in late April, and got the impression
> that they didn't have time and were momentarily dropping CLRFIs that
> were submitted. Probably due to the ALU convention, and they may get
> that post-convention motivational bounce to work on this stuff.
>
> Unfortunately, they apparently do not have a viewable archive of all
> submissions. Therefore it seems wise to post them in a public wiki or
> website before emailing clrfi-editors.
Or perhaps on Usenet? If only I could find a relevant newsgroup...
-- MJF
M Jared Finder wrote:
> Tayssir John Gabbour wrote:
> > M Jared Finder wrote:
> >>This reminds me, is there some reason that CLRFIs never got anywhere?
> >>This is such a simple thing to implement, that I'm sure that everyone
> >>has their own implementation. It'd sure be nice to have a standard
> >>package for this.
> >
> > I spoke with Nick Levine about it in late April, and got the impression
> > that they didn't have time and were momentarily dropping CLRFIs that
> > were submitted. Probably due to the ALU convention, and they may get
> > that post-convention motivational bounce to work on this stuff.
> >
> > Unfortunately, they apparently do not have a viewable archive of all
> > submissions. Therefore it seems wise to post them in a public wiki or
> > website before emailing clrfi-editors.
>
> Or perhaps on Usenet? If only I could find a relevant newsgroup...
Sure; ironic on many levels that I didn't mention it...
CLisp's Sam Steingold submitted a CLRFI:
I submitted one.
I never heard from them - other than "yes, you jumped through all
our hoops, the ball is on our side now".
If I am not alone, we could start an emotional support group -
"CLRFI authors neglected by the CLRFI editors".
http://groups-beta.google.com/group/comp.lang.lisp/msg/498d8738d4d45440?hl=en
Then he suggested "why not put up _everything_ you received and let the
public post comments? (A la 'an open review')". So perhaps editors can
come from the public, and it may be a bit more merit-based.
http://groups-beta.google.com/group/comp.lang.lisp/msg/e3793c041808c9d1?hl=en
It is very doubtful Sam's suggestion will be taken. The editors may
perhaps be increasingly more efficient after these conferences, but
CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
open review is simply outside the goal of CLRFI. Another harmonious
mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
Tayssir
Tayssir John Gabbour wrote:
>
> Then he suggested "why not put up _everything_ you received and let the
> public post comments? (A la 'an open review')". So perhaps editors can
> come from the public, and it may be a bit more merit-based.
> http://groups-beta.google.com/group/comp.lang.lisp/msg/e3793c041808c9d1?hl=en
>
> It is very doubtful Sam's suggestion will be taken. The editors may
> perhaps be increasingly more efficient after these conferences, but
> CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
> open review is simply outside the goal of CLRFI. Another harmonious
> mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
Allow me to take this personally.
The CLRFI organizers (not editors) have very limited time.
The intention, at least on my part has always been to have the process
really really open. Alas, I am also of the opinion that there is
something between the cathedral and the bazaar.
Now. There are still open issues with the CLRFI process (the other
organizers can jump in at any time)
1 - there are *no* editors yet. (I proposed and strongly strongly
support the principle, "one implementation or one affiliation, one
editor"; I also liked the idea of having one representative per "Lisp
user group", so that the people from - say - Seattle or Milan can have
one person in(*)). Having said that, again, there are no "editors" yet.
2 - the machinery (read, the web site) is not up and running yet. The
reasons are twofold: the organizers have limited time, and there is no
consensus about what is a good infrastructure. Sam proposed
'livejournal'. It is a possibility, but it may or may not work.
3 - there are some issues about legal claims by this or that actor,
should they feel "left out". These are not issues to be treated
lightly, although my personal opinion is that they should not be show
stoppers either.
4 - all in all, there are still issues about what CLRFI should
"standardize". My opinion is that it shouldn't really "standardize"
(quotes mandatory). It should provide an avenue to foster consensus and
a set of practices to make sure that implementations have an incentive
to provide the "consented upon" submissions. Moreover, the submissions
must be allowed to range from the trivial, to the major ones ("let's fix
the pathnames" anyone?)
Finally, CLRFI should all be about "open review" and "quality". That is
why the mechanisms to ensure that such reviews and quality control are
in place and are handled fairly is not easy to set up.
Now. If you have any good idea about a web based system (e.g.
livejournal or similar) to be used as infrastructure, you are welcome to
make suggestions. If you have time to spare to actually work on the
project, I will not have any problem accepting your time and work, as
long as you are willing to discuss the isses and not dismiss them as
trivial, or worse, ill-intentioned. And no. AFAIK there is no easy way
out, otherwise, CLiKI would be chocked full of proposals (there are
some), and it is not.
Cheers
--
Marco
(*) Of course, Lispnyc deserves the absolute majority on the editors'
table, but that is another story :)
Marco Antoniotti wrote:
> Tayssir John Gabbour wrote:
> > Then he suggested "why not put up _everything_ you received and let the
> > public post comments? (A la 'an open review')". So perhaps editors can
> > come from the public, and it may be a bit more merit-based.
> > http://groups-beta.google.com/group/comp.lang.lisp/msg/e3793c041808c9d1?hl=en
> >
> > It is very doubtful Sam's suggestion will be taken. The editors may
> > perhaps be increasingly more efficient after these conferences, but
> > CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
> > open review is simply outside the goal of CLRFI. Another harmonious
> > mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
>
> Allow me to take this personally.
>
> The CLRFI organizers (not editors) have very limited time.
I accept you want to take this to a personal level. Your time and
stress is personal.
When you say, "Write the spec, back it up by a portable implementation,
and submit it," you are telling this to individuals with similarly
limited time. Perhaps putting out fires for their clients, as I have
been this weekend.
If you have knowledge that you do not have editors in place, and after
having read a busy CLRFI submitter's half-joke about an "emotional
support group" for people ignored by CLRFI editors... is this
respectful of people's time constraints?
> Now. If you have any good idea about a web based system (e.g.
> livejournal or similar) to be used as infrastructure, you are welcome to
> make suggestions.
Could you please enlighten us what the problem is, of clicking the
button which makes the ·············@... archives open to web-viewing?
(And of course, any proposal sent through some other channel should be
forwarded to that mailing list.)
Tayssir
Tayssir John Gabbour wrote:
> Marco Antoniotti wrote:
> > Tayssir John Gabbour wrote:
> > > Then he suggested "why not put up _everything_ you received and let the
> > > public post comments? (A la 'an open review')". So perhaps editors can
> > > come from the public, and it may be a bit more merit-based.
> > > http://groups-beta.google.com/group/comp.lang.lisp/msg/e3793c041808c9d1?hl=en
> > >
> > > It is very doubtful Sam's suggestion will be taken. The editors may
> > > perhaps be increasingly more efficient after these conferences, but
> > > CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
> > > open review is simply outside the goal of CLRFI. Another harmonious
> > > mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
> >
> > Allow me to take this personally.
> >
> > The CLRFI organizers (not editors) have very limited time.
>
> I accept you want to take this to a personal level. Your time and
> stress is personal.
>
> When you say, "Write the spec, back it up by a portable implementation,
> and submit it," you are telling this to individuals with similarly
> limited time. Perhaps putting out fires for their clients, as I have
> been this weekend.
>
> If you have knowledge that you do not have editors in place, and after
> having read a busy CLRFI submitter's half-joke about an "emotional
> support group" for people ignored by CLRFI editors... is this
> respectful of people's time constraints?
>
>
> > Now. If you have any good idea about a web based system (e.g.
> > livejournal or similar) to be used as infrastructure, you are welcome to
> > make suggestions.
>
> Could you please enlighten us what the problem is, of clicking the
> button which makes the ·············@... archives open to web-viewing?
>
> (And of course, any proposal sent through some other channel should be
> forwarded to that mailing list.)
Incidentally, I do not wish this to be about "you you you", as my email
must sound. I've also had to answer for organizations that did eat up a
bit of time, and have shared responsibility for it.
I simply want to understand that last question, about ·············@...
archives open to web-viewing.
Tayssir John Gabbour wrote:
> Marco Antoniotti wrote:
>
>>Tayssir John Gabbour wrote:
>>
>>>Then he suggested "why not put up _everything_ you received and let the
>>>public post comments? (A la 'an open review')". So perhaps editors can
>>>come from the public, and it may be a bit more merit-based.
>>>http://groups-beta.google.com/group/comp.lang.lisp/msg/e3793c041808c9d1?hl=en
>>>
>>>It is very doubtful Sam's suggestion will be taken. The editors may
>>>perhaps be increasingly more efficient after these conferences, but
>>>CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
>>>open review is simply outside the goal of CLRFI. Another harmonious
>>>mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
>>
>>Allow me to take this personally.
>>
>>The CLRFI organizers (not editors) have very limited time.
>
>
> I accept you want to take this to a personal level. Your time and
> stress is personal.
>
> When you say, "Write the spec, back it up by a portable implementation,
> and submit it," you are telling this to individuals with similarly
> limited time. Perhaps putting out fires for their clients, as I have
> been this weekend.
>
> If you have knowledge that you do not have editors in place, and after
> having read a busy CLRFI submitter's half-joke about an "emotional
> support group" for people ignored by CLRFI editors... is this
> respectful of people's time constraints?
It was not my intention to be disrespectful and I apologize for being so.
I just ask you to just take my comments at face value. It just happens
that in the past few months I simply did not have much time for way too
many things (maybe I bullshit too much on CLL, but that is just a
relaxing time of the day for me).
>>Now. If you have any good idea about a web based system (e.g.
>>livejournal or similar) to be used as infrastructure, you are welcome to
>>make suggestions.
>
>
> Could you please enlighten us what the problem is, of clicking the
> button which makes the ·············@... archives open to web-viewing?
I personally do not have any problem with that. If the other organizers
agree, it will be fine with me to open it up.
> (And of course, any proposal sent through some other channel should be
> forwarded to that mailing list.)
Of course. The proposals do come through the mailing list.
Yet, what comes next is tricky and not automated. The idea was to have
an opne mailing list for discussion associated to each incoming
proposal, along with voting procedures and an appeal process. Alas,
this has not be set in place.
Cheers
--
Marco
Marco Antoniotti wrote:
> > Could you please enlighten us what the problem is, of clicking the
> > button which makes the ·············@... archives open to web-viewing?
>
> I personally do not have any problem with that. If the other organizers
> agree, it will be fine with me to open it up.
>
> > (And of course, any proposal sent through some other channel should be
> > forwarded to that mailing list.)
>
> Of course. The proposals do come through the mailing list.
>
> Yet, what comes next is tricky and not automated. The idea was to have
> an open mailing list for discussion associated to each incoming
> proposal, along with voting procedures and an appeal process. Alas,
> this has not be set in place.
I think that a more lightweight approach would yield good results. For
example, check out the bulletin board I set up at
<http://phpbb-host.com/phpbb/?mforum=clrfi>. Each CLRFI can be posted
as a seperate thread, and then people can talk about them. There is a
voting mechanism, although it's probably not what you're looking for.
My idea is that the bulletin board can be for hashing out proposals,
and the main CLRFI site can be for more final things... but it's just a
proposal, and if nobody like the forum idea I'll take it down.
I just want to get things moving, and I have some spare time.
On Thu, 09 Jun 2005 20:51:32 -0700, Peter Scott wrote:
> My idea is that the bulletin board can be for hashing out proposals, and
> the main CLRFI site can be for more final things... but it's just a
> proposal, and if nobody like the forum idea I'll take it down.
(i.e. <http://phpbb-host.com/phpbb/?mforum=clrfi>)
Another suggestion that may have extra appeal to those using this medium:
Let's also start using the preexisting Usenet group comp.std.lisp:
<http://groups-beta.google.com/group/comp.std.lisp/about>
I posted a test message that hasn't got through yet so moderation is still
in operation. If the ALU can turn off the moderation it could be a useful
standards forum much like comp.std.c:
<http://groups-beta.google.com/group/comp.std.c/about>
As it stands the last non-spam post to comp.std.lisp appears to be this
1998 post by Kent M Pitman:
<http://groups-beta.google.com/group/comp.std.lisp/msg/6c75e9588de9f8fc>
Because ANSI/ISO C is such a popular language comp.lang.c almost strictly
deals with answering questions about code intending to conform with K&R C,
C89 or C99. If ANSI Common Lisp continues to grow in popularity there may
need to be a separate Usenet outlet to hash out extensions to Common Lisp
(i.e. comp.std.lisp) to keep traffic in comp.lang.lisp at a comfortable
level.
Regards,
Adam
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Allow me to take this personally.
Take the following as you wish.
> The CLRFI organizers (not editors) have very limited time.
Did the fact that a bunch of people got together at a conference,
announced a process, put up a website, and then did nothing much for
two years inhibit other efforts, which might actually have borne
fruit, towards the same goal?
If such a situation could hold, might it be a good thing for
"organizers" of a process who are unwilling or unable to do any kind
of timely organization to publically say as much and, failing an
influx of manpower, officially wind up their efforts?
Christophe
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Allow me to take this personally.
>
>
> Take the following as you wish.
>
>
>>The CLRFI organizers (not editors) have very limited time.
>
>
> Did the fact that a bunch of people got together at a conference,
> announced a process, put up a website, and then did nothing much for
> two years inhibit other efforts, which might actually have borne
> fruit, towards the same goal?
First of all in what way were other efforts (which ones?) inhibited?
Secondly, as far as I am concerned, the group of organizers never
announced a schedule for actually getting the thing "officially" started.
> If such a situation could hold, might it be a good thing for
> "organizers" of a process who are unwilling or unable to do any kind
> of timely organization to publically say as much and, failing an
> influx of manpower, officially wind up their efforts?
Yes. That may also be the case. Given my personal situation I can
agree with that and I will be glad to discuss it at ILC. Again. As far
as I am concerned, people will be welcome to chip in.
However, so far the CLRFI web site and process are the best we have.
You may not agree with it, but that's the way I see it.
Having said that, you are free to make a counter proposal, set up a web
site, or join in. So far I have not seen any counter proposal save a
few (some good - mostly by Bruno Haible - some not) pages on Cliki. So
why don't you join in? Have you ever even asked to join?
Cheers
--
Marco
From: Sam Steingold
Subject: Re: CLRFI (Re: Alternatives to OO?)
Date:
Message-ID: <uhdg75rar.fsf@gnu.org>
> * Marco Antoniotti <·······@pf.alh.rqh> [2005-06-09 13:44:22 -0400]:
>
> However, so far the CLRFI web site and process are the best we have.
This is where we disagree.
I do NOT think that "CLRFI web site and process" is something we "have".
(The web site is there, but nothing visible is happening.)
We do NOT have ANYTHING for adding stuff to CL.
And the CLRFI web presence hides this fact.
Thus I believe that the CLRFI _may_ have done a disservice to the CL
community by potentially discouraging other efforts (if any) in the same
direction.
[Note that I am _not_ saying that CLRFI actually _did_ a disservice.]
IMHO you have an obligation to either make sure CLRFI moves forward,
or to formally and officially _shut down_ your web site.
E.g., you must at the very least make public the CLRFIs that you have
already received. One way to do that is to create a CLRFI group on
livejournal.com and post links to each CLRFI as a note. A forum for
discussing the CLRFI will automatically be created and people will be
able to post comments.
Alternatively, individual CLRFI authors can post their proposals to
<http://www.livejournal.com/community/lisp/>.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.palestinefacts.org/>
<http://www.honestreporting.com> <http://ffii.org/> <http://www.memri.org/>
Those who don't know lisp are destined to reinvent it, poorly.
Sam Steingold <···@gnu.org> writes:
> Thus I believe that the CLRFI _may_ have done a disservice to the CL
> community by potentially discouraging other efforts (if any) in the same
> direction.
At ILC 2002 Kent Pitman proposed his "substandards" process:
http://substandards.org/
His paper is in the conference proceedings.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Christophe Rhodes wrote:
>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>The CLRFI organizers (not editors) have very limited time.
>> Did the fact that a bunch of people got together at a conference,
>> announced a process, put up a website, and then did nothing much for
>> two years inhibit other efforts, which might actually have borne
>> fruit, towards the same goal?
>
> First of all in what way were other efforts (which ones?) inhibited?
Well, I asked you the question to see if you could come up with any
mechanism (I haven't actually asserted that any such efforts were
inhibited). Since you haven't come up with one, here are some which I
can imagine might happen (again, no assertion):
* someone with energy and enthusiasm to do infrastructural work does
not do so, because he assumes that the announced, referred-to,
discussed-at-conferences CLRFI project has this in hand;
* someone submits a CLRFI to the CLRFI project, whereupon it sits in
limbo for an unspecified amount of time.
> Secondly, as far as I am concerned, the group of organizers never
> announced a schedule for actually getting the thing "officially"
> started.
On the other hand, it has been trailed at meetings and conferences
over the last two years.
> However, so far the CLRFI web site and process are the best we
> have. You may not agree with it, but that's the way I see it.
"The best we have" can still be worse than not having anything at all.
> Having said that, you are free to make a counter proposal, set up a
> web site, or join in. So far I have not seen any counter proposal
> save a few (some good - mostly by Bruno Haible - some not) pages on
> Cliki. So why don't you join in? Have you ever even asked to join?
My contribution to CLRFI so far has been limited to fixing some of the
most egregious bugs in the trial CLRFI[*], on the basis that it would
be really embarrassing if the Lisp community couldn't even get /that/
right. Such modifications appear to be uncredited in the CLRFI text,
and the mail archives involved are not publically accessible, so only
the CLRFI organizers can in fact know this.
As for my own part in standards processes, apart from participating in
documentation and discussion of the approximately 70 separate issues
at
<http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications>
I have discussed with other lisp vendors the possibility for common
extensions. I have not asked to "join" CLRFI because I think it
actually acts as a barrier in the way of people creating and
documenting things they need.
Christophe
[*] some might ask how it's possible that such a simple function and
specification could possibly have bugs. Nevertheless, it did, and in
part this is why standardization is so hard: it's easy to make
mistakes.
Tayssir John Gabbour wrote:
> It is very doubtful Sam's suggestion will be taken. The editors may
> perhaps be increasingly more efficient after these conferences, but
> CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
> open review is simply outside the goal of CLRFI. Another harmonious
> mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
Sometimes I wish that a simple amazon-style recommendation system would
be nice: "Other people who like Screamer also use the Series package."
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Tayssir John Gabbour wrote:
>
>> It is very doubtful Sam's suggestion will be taken. The editors may
>> perhaps be increasingly more efficient after these conferences, but
>> CLRFI's goal is to be a process-oriented bureaucracy. Which is fine;
>> open review is simply outside the goal of CLRFI. Another harmonious
>> mechanism is needed, such as a simple usenet/blog/wiki/whatever post.
>
>
> Sometimes I wish that a simple amazon-style recommendation system would
> be nice: "Other people who like Screamer also use the Series package."
Too much wishful thinking here. ;)
Make this either: "Sometimes I wish that ... existed: ..." or "Sometimes
I think that ... would be nice: ...".
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
>>>>> "PC" == Pascal Costanza <··@p-cos.net> writes:
[...]
PC> Sometimes I wish that a simple amazon-style recommendation
PC> system would be nice: "Other people who like Screamer also use
PC> the Series package."
Actually this is not necessarily impractical. Might even be
valuable. One can perhaps look at what symbols are referenced and try
to infer the programming style and (1) what subset of CL a particular
programmer is using and (2) go from there to package usage. There is
enough lisp code online with known authors so someone could attempt
this. Hmm? I also often think collecting click-stream info from the
online hyperspec could be useful in coming up with a scheme for
guiding newbies.
cheers,
BM
M Jared Finder wrote:
> Paul F. Dietz wrote:
>
>> Andreas Thiele wrote:
>>
>>>> Any sufficiently complicated Common Lisp program that tries to avoid
>>>> using parts of Common Lisp will contains an ad-hoc,
>>>> informally-specified, bug-ridden, slow re-implementation of the other
>>>> half of Common Lisp it did not want to use in the first place.
>>>
>>>
>>> This is exactly why I decided to go the CLOS way :)
>>
>>
>> I sometimes wish parts of Common Lisp itself had gone the CLOS
>> way. It would be nice if (for example) sequence functions were
>> actually generic. This needn't be any less efficient on standard
>> sequences than current implementations (basically, where the current
>> implementation would signal an error, the generic version would
>> first look for user-defined methods.)
>
>
> This reminds me, is there some reason that CLRFIs never got anywhere?
> This is such a simple thing to implement, that I'm sure that everyone
> has their own implementation. It'd sure be nice to have a standard
> package for this.
Write the spec, back it up by a portable implementation, and submit it.
Cheers
--
Marco
I just read that article last night and enjoyed it a lot. I feel that he
was more saying how Lisp has so many of the nice features of Objects
already, that he doesn't feel the need to overlay an object system on
top. I find it to be a cool idea. He doesn't disagree with all parts of
OO, just the parts that are wastefull and pointless that some other
languages enforce. It is an interesting and very cool idea (especially
coming out of college where they shove Java and OO at you)
Kelsin
Andreas Thiele wrote:
> "A.L." <·················@hotfuck.com> schrieb im Newsbeitrag
> ·······································@4ax.com...
>
>>On Mon, 6 Jun 2005 11:43:16 +0200, "Andreas Thiele"
>><······@nospam.com> wrote:
>>
>>
>>>I just wrote my own MOP extension to CLOS which maps OO to Entity
>>>Relationsship. One of my whole systems goals is avoiding duplicate work.
>>>
>>>Paul Graham is utterly against OO at all. In his assay
>>>
>>>http://paulgraham.com/noop.html
>>
>>His opinion is pure nonsense:
>>
>>"I personally have never needed object-oriented abstractions. Common
>>Lisp has an enormously powerful object system and I've never used it
>>once. I've done a lot of things (e.g. making hash tables full of
>>closures) that would have required object-oriented techniques to do
>>in wimpier languages, but I have never had to use CLOS..."
>>
>>A.L.
>
>
> I am not sure :)
>
> I mean obviously he wrote a huge and _succesful_ application.
>
> Using a property list containing some functions/closures/lambdas like
>
> (setf object '(medthod-x (lambda ... ) method-y ... ))
>
> and using (funcall (getf object method-x) ...) we already have something
> equivalent to a simple object with polymorphism.
>
> Perhaps one should consider his references
>
> http://paulgraham.com/reesoo.html
>
> and
>
> http://mumble.net/~jar/articles/oo.html
>
> as well.
>
>
> Andreas
>
> P.S. I find it more interesting to understand his point of view than judging
> if he is wrong or right.
>
>
>
Kelsin <······@valefor.com> writes:
> I just read that article last night and enjoyed it a lot. I feel that
> he was more saying how Lisp has so many of the nice features of
> Objects already, that he doesn't feel the need to overlay an object
> system on top.
I had some resistance to CLOS myself, until 8 or 9 years ago. The
background was both the fascinating fact that you can roll your own OO
in a few lines of lisp code (let's see, I think I did that too once,
yes, I found it: A minimalist object system, weighing in at only 35
LOC, written in '89 a few months after I started with common lisp :-))
and the fact that I had a some experience with a beuatiful little
object extension to common lisp that was very different from CLOS
(namely Object Lisp).
But the fact is that if you reject CLOS, you're rejecting a large
set of extremely useful tools that makes Common Lisp programming
even more fun.
If you use CL without CLOS, you're simply missing out on a lot of its
capabilities and power. It's sort of like using a Land Rover just
for downtown city driving :-)
--
(espen)
A.L. wrote:
> His opinion is pure nonsense:
>
> "I personally have never needed object-oriented abstractions. Common
> Lisp has an enormously powerful object system and I've never used it
> once. I've done a lot of things (e.g. making hash tables full of
> closures) that would have required object-oriented techniques to do
> in wimpier languages, but I have never had to use CLOS..."
This quote is not an opinion but a summary of his experience, in what
way can it be "nonsense"?
mkb.
Andreas Thiele wrote:
> I just wrote my own MOP extension to CLOS which maps OO to Entity
> Relationsship. One of my whole systems goals is avoiding duplicate work.
>
> Paul Graham is utterly against OO at all. In his assay
>
> http://paulgraham.com/noop.html
>
> he says for example: "Object-oriented programming is exciting if you have a
> statically-typed language without lexical closures or macros. To some
> degree, it offers a way around these limitations."
>
> Although I do not think he is wrong, I have no idea how I could replace my
> own system. I am interested in new ideas.
>
> Can somebody give me a more explanatory hint on alternatives than just
> mentioning closures and macros?
> What reading can make me agree to PG?
If you focus on inheritance, OOP is basically a way to incrementally
define programs: A given number of classes defines a program, and when
you add new subclasses and override methods on those classes you get a
new, more specialized program. (The new classes will only have an effect
if you actually create instances of the new classes and throw them into
the mix of existing objects.)
One of the problems with this notion of incremental programming is that
there are no enforced rules on how to build the new increments, even
though they would be necessary, or at least useful. So you usually get
some documentation on how you should override methods, especially about
how to override them in conjunction. I am not aware of a good example in
ANSI Common Lisp, but there are a number of examples in CLOS MOP, and
very likely in other CLOS-based code. For example, the MOP specification
tells us that one should only override ADD-METHOD when one also
overrides REMOVE-METHOD and FIND-METHOD.
Another approach to incremental programming is to use modules with
functors. A functor is a function that transforms a module into another
module. Such a functor may take several arguments that specify the
actual transformation. They could, for example, take definitions for
ADD-METHOD, REMOVE-METHOD and FIND-METHOD and additionally check whether
you actually redefine them in conjunction instead of just "colloquially"
suggesting this. The claim is that you don't need OOP anymore if you
have functors. (I think this only works when you can anticipate all ways
how one may want to transform a module, which seems to me like a strong
restriction. But I have never really used a functor-based approach, so I
can't really tell.)
There are papers about this approach at http://readscheme.org/modules/
and you can find some useful stuff by googling for "ML functors".
I also don't know whether this is what Paul Graham had in mind.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
"Andreas Thiele" <······@nospam.com> wrote:
> Can somebody give me a more explanatory hint on alternatives than just
> mentioning closures and macros?
> What reading can make me agree to PG?
The point isn't that there is some "non-object-oriented methodology"
that you should be adopting.
It is instead that you should be looking at problems and trying to
solve them on their own terms.
A doctrinaire "object oriented" approach involves problem solving via
trying to construct a hierarchy of objects and methods, and trying to
pigeonhole everything into being an object of one variety or another.
There may be cases where it _is_ meaningful to build a hierarchy for
some set of "related things." Graphical libraries seem particularly
amenable to this; imposing a hierarchy is useful in making them
comprehensible, particularly if there are hundreds of API calls.
In contrast, if you're solving some mathematical problem, while there
may be places where having some objects and methods for expressing
vectors and matrices and such, the "non-OO way" is that you don't
bother trying to force methods and data types to all fit into some
cookie-cutter OO hierarchy of related classes/methods.
Solve the real problem; don't solve the artificial problem of trying
to impose an object structure.
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/languages.html
How much deeper would the ocean be if sponges didn't live there?
On 4297 September 1993, Christopher Browne wrote:
> "Andreas Thiele" <······@nospam.com> wrote:
>> Can somebody give me a more explanatory hint on alternatives than just
>> mentioning closures and macros?
>> What reading can make me agree to PG?
> The point isn't that there is some "non-object-oriented methodology"
> that you should be adopting.
> It is instead that you should be looking at problems and trying to
> solve them on their own terms.
> A doctrinaire "object oriented" approach involves problem solving via
> trying to construct a hierarchy of objects and methods, and trying to
> pigeonhole everything into being an object of one variety or another.
Is that a wrong approach per se? I don't think so (and take it from
the rest of your message that you don't either). There is certainly a
problem space for which an OO style might not be the best one. I also
strongly believe that for a lot of problems, OOP is not at all
necessary. But it still might be worthy to use it anyway. Perhaps I'm
just a mediocre programmer, but to me, using an OOP approach forces me
to think about funtionality and data and their relations, and even
more important, their useful abstractions. I see that as a benefit.
E.g., in a recent application I rewrote (not refactor), all of the
functionality and required data objects had been implemented using
plain Common Lisp data types like e.g. hash tables and vectors and
their corresponding functions. The application was running just fine.
However, I wanted to see the impact different implementations would
have, both on the implementation itself (wrt. to length of source
code as well as it's elegance) as well as on the resulting performance
(speed and space required). It turned out that the code missed the
required abstractions and hence "trying different implementations" was
more hassle than I expected. Using CLOS in the first place would have
probably allowed me to sweep these differences in the implementation
under the interface carpet (and hence would have allowed refactoring
instead of rewriting) and would have make me think about sensible
abstractions first.
If PG didn't ever need OOP, he's probably clever enough to come up
with good abstractions even without it or he doesn't have had to deal
a lot with substantial code revisions (that's an inclusive or).
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Subject: Zitate aus [...]
Newsgroups: de.rec.sf.misc"
-- Aus "Wie starte ich einen Endlosthread ?", Teil 715
Holger Schauer <··············@gmx.de> writes:
> If PG didn't ever need OOP, he's probably clever enough to come up
> with good abstractions even without it or he doesn't have had to deal
> a lot with substantial code revisions (that's an inclusive or).
I would argue SICP is a book about OOP.
It's all a matter of using abstractions.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Andreas Thiele wrote:
> I just wrote my own MOP extension to CLOS which maps OO to Entity
> Relationsship. One of my whole systems goals is avoiding duplicate work.
>
> Paul Graham is utterly against OO at all. In his assay
>
> http://paulgraham.com/noop.html
>
> he says for example: "Object-oriented programming is exciting if you have a
> statically-typed language without lexical closures or macros. To some
> degree, it offers a way around these limitations."
I don't think that what he wrote is totally against it;
He acknowledges it as a useful technique, after all.
In my opinion, good programmers did what would now be
called Object-Oriented code, where appropriate, long
before it became an idea around which languages were
designed. "Object Oriented" had been known for many
years in languages like simula, but was starting to
achieve buzzword status around my senior year of college.
I had for years already been analyzing problems in
terms of data invariants, and considering data along
with all the code that worked on that data, in terms
of whether or not the code preserved those invariants;
back when, it was called "ADT programming", and it
was just a technique, not a language extension. But
it had largely the same goals, stated purposes, and
techniques as what is now called "object oriented."
When I started hacking scheme, I made fully encapsulated
thingies that had their own behavior inside them and exposed
a limited interface to the outside world ... but I didn't
need an "object system" to do it, I just used closures.
I still don't use much of CLOS. Generic functions are very
handy, and they break down the problems the way *I* think
of the problems (which is more verb-oriented than object-
oriented, I guess). But as for inheritance, multiple or
otherwise, I can take or leave it; as far as I'm concerned
I'd be just as happy if "classes" were defined strictly
in terms of what interfaces they implement.
The real value of OO, as far as I'm concerned, is that
it partitions your code and the problem in such a way
that lots of other people's code and structure can be
used in addition to your own. It provides a set of
conventions that allow a community broader than a single
shop to write code that will be useful to each other.
But it's certainly not the only possible way to break
problems down, nor is it the only good way. And for
lots of problems, it isn't the best way.
For problems that are more mathematics-oriented,
functional programming is usually better than
Object-Oriented programming, for example. For problems
where most things can be used *somehow* for most purposes,
but each has a few uses for which it's "most natural", I
tend to prefer Data Directed code instead of Object-
Oriented. For encapsulation problems and enforcement of
invariants, where there's no significant behavior to inherit,
I use OO extensions in a language to implement "objects"
frequently without any hierarchy at all - which my old
profs would recognize as ADT programming. For simulation
and event-handling where the things simulated are simple
and limited, Object-Oriented is hands down the best way
to do it. For simulation and event-handling where you
have to take into account interactions that may go
unforseen even to you, logic programming is an
irreplaceable but expensive technique that may serve
best.
Honestly, and meaning no offense, I think it's shameful
that you can graduate from college these days and not learn
more than one paradigm of computing. OO, DD, FP, LP, ADT,
MP, and several others, are all sometimes the appropriate
tool for the job.
Bear
> Although I do not think he is wrong, I have no idea how I could replace my
> own system. I am interested in new ideas.
>
> Can somebody give me a more explanatory hint on alternatives than just
> mentioning closures and macros?
> What reading can make me agree to PG?
>
> Andreas
>
>
Remember that Objects are a combination of "state" (in the form of
member data) along with functions that operate on it.
I almost never use object abstractions (except at my day job) and
instead use functional programming along with DSLs.
Objects don't really have any meaning in pure functional programming
since FP tries to remove state- Although "types" in the more abstract
sense have a clear use.
I would also argue that DSLs, in their pure form, don't really directly
benefit from OOP, since a DSL program would be in the form of a syntax
expression, where the first parameter in every list potentially
represents a "command" with the other parameters as data for that
command- A Lisp sexp form simply serializes much cleaner than a CLOS
object (it is the most fundamental Lisp data structure, after all...)
and therefore using CLOS for parsing/processing a DSL isn't as elegant
as just using plain ol' lisp with sexps.
I think (but don't know for sure) that Paul Graham is arguing that a
combination of functional programming and writing lots of the "brains"
of your program in custom DSLs is superior to OOP. I find this to be
the case from my own experience, anyway...
Conrad Barski, M.D.
<······@gmail.com> schrieb im Newsbeitrag
····························@g14g2000cwa.googlegroups.com...
> Remember that Objects are a combination of "state" (in the form of
> member data) along with functions that operate on it.
>
> I almost never use object abstractions (except at my day job) and
> instead use functional programming along with DSLs.
>
> Objects don't really have any meaning in pure functional programming
> since FP tries to remove state- Although "types" in the more abstract
> sense have a clear use.
Sorry, I'm not an FP specialist, but what do you do if your program has to
handle state, lets say to handle a bank account?
>
> I would also argue that DSLs, in their pure form, don't really directly
> benefit from OOP, since a DSL program would be in the form of a syntax
> expression, where the first parameter in every list potentially
> represents a "command" with the other parameters as data for that
> command- A Lisp sexp form simply serializes much cleaner than a CLOS
> object (it is the most fundamental Lisp data structure, after all...)
> and therefore using CLOS for parsing/processing a DSL isn't as elegant
> as just using plain ol' lisp with sexps. ...
Even if processing of a DSL wouldn't benefit from OO, I see no reason why
the DSL itself should not work on objects.
> ...
> I think (but don't know for sure) that Paul Graham is arguing that a
> combination of functional programming and writing lots of the "brains"
> of your program in custom DSLs is superior to OOP. ...
I don't believe, this can be a sufficient answer. Graham is a 'Lisp advokat'
and Lisp is not restricted to functional programming!?
DSLs might be the point.
> ... I find this to be
> the case from my own experience, anyway...
>
> Conrad Barski, M.D.
>
> Sorry, I'm not an FP specialist, but what do you do if your program has to
> handle state, lets say to handle a bank account?
In that case, the goal would be to minimize the "stateful" part of the
program to be as small a part of the program as possible- An sexp of
the transactions on the bank account could represent the stateful data.
Purely functional functions could then be written to accept the
structure, and return a new structure with modifications- The reason
this is different from an object with state that only 1 (possibly very
complex) stateful structure would be used in the entire application
-Which is essentially equivalent to a monad in languages that handle
monadic abstractions.
> Even if processing of a DSL wouldn't benefit from OO, I see no reason why
> the DSL itself should not work on objects.
True, but the issues are linked, I think: If it is advantageous to have
a primare that [does]/[does not] use objects then equally it would be
advantageous that the DSLs built from it that [do]/[do not] support
object abstractions themselves. One of the great advantages of Lisp is
that DSLs can be easily created by having them "borrow" functionality
of the host language- and so the value of objects in one might possibly
be reflected on the other.
> I don't believe, this can be a sufficient answer. Graham is a 'Lisp advokat'
> and Lisp is not restricted to functional programming!?
He seems to be particularly fond of the FP aspects of lisp, I find.
Note his disdain of LOOP and CLOS- FP arguably receives more coverage
than either of these in his books. But you are right that he likes
imperative parts as well, so he is clearly not motivated entirely by
FP, for sure.
<······@gmail.com> schrieb im Newsbeitrag
····························@g49g2000cwa.googlegroups.com...
> > Sorry, I'm not an FP specialist, but what do you do if your program has
to
> > handle state, lets say to handle a bank account?
>
> In that case, the goal would be to minimize the "stateful" part of the
> program to be as small a part of the program as possible- An sexp of
> the transactions on the bank account could represent the stateful data.
> Purely functional functions could then be written to accept the
> structure, and return a new structure with modifications- The reason
> this is different from an object with state that only 1 (possibly very
> complex) stateful structure would be used in the entire application
> -Which is essentially equivalent to a monad in languages that handle
> monadic abstractions.
>
My own libs offer an extension to CLOS (which itself is a DSL) to be used in
application programming, but most of the systems power comes from several
DSLs and the system itself contains only very little OO.
Meanwhile I read a little about FP state representation in SICP. I must
admit, I have to dive in a little deeper. As far as I understand
Abelson/Sussman both approaches have substancial difficulties.
Thanks for your hints.
Andreas
You know, the more I think about it, my own philosophy on this matter
seems to boil down to this:
Procedural programming (ala vanilla C) is a great technique for
abstraction, but I believe everyone can agree that it is still greatly
suboptimal for many problems (let's say it can capture ~30% of problems
well). Because of this, some sort of orthogonal technique must be added
to procedural programming to allow most problem domains to be described
adequately.
The thing is, that there are several such orthogonal techniques:
1. OOP/AOP
2. FP
3. DSL
4. Higher Order Functor Techniques
Each of these techniques adds some type of additional indirection to a
basic procedural design and offer significant benefits in exchange
(let's say they can bring our expressivity from ~30% ==> ~80%) They
also have some costs:
1. OOP/AOP - Decreases brevity significantly, prone to "object
spagetti"
2. FP - Can be slow, requires more cognitive effort to design
3. DSL - Can be slow, Decreases brevity (extra code to "Execute"
DSL code), designing a good DSL is hard
4. HOF - Can become esoteric and brittle
The reason OOP/AOP is the most popular of these, it could be argued, is
a historical accident having to do with Moore's law- It had the least
performance hit of all the techniques (I'm talking performance in the
eyes of a "naive" use of these techniques)...
...but Moore has caught up, possibly giving the other techniques an
edge.
Another interesting fact is that all these techniques are arguably
orthogonal to each other as well: By using all of them (which only lisp
can really do well) one can ramp up even higher, let's say from ~80 ==>
~95 of common problem domains handled well- Of course, using these
techniques is so cognitively difficult that few (if any) developers can
do it well at this point in time...
that's my $0.02
Conrad Barski, M.D.
······@gmail.com wrote:
> You know, the more I think about it, my own philosophy on this matter
> seems to boil down to this:
>
> Procedural programming (ala vanilla C) is a great technique for
> abstraction,
Hunh?
> ...but I believe everyone can agree that it is still greatly
> suboptimal for many problems (let's say it can capture ~30% of problems
> well). Because of this, some sort of orthogonal technique must be added
> to procedural programming to allow most problem domains to be described
> adequately.
Nothing is added to procedural programming. The things you list relegate
the procedural to a bit part in application development.
>
> The thing is, that there are several such orthogonal techniques:
>
> 1. OOP/AOP
> 2. FP
> 3. DSL
> 4. Higher Order Functor Techniques
5. Dataflow
>
> Each of these techniques adds some type of additional indirection to a
> basic procedural design and offer significant benefits in exchange
> (let's say they can bring our expressivity from ~30% ==> ~80%) They
> also have some costs:
>
> 1. OOP/AOP - Decreases brevity significantly, prone to "object
> spagetti"
> 2. FP - Can be slow, requires more cognitive effort to design
> 3. DSL - Can be slow, Decreases brevity (extra code to "Execute"
> DSL code), designing a good DSL is hard
Slow? It is just macrology.
Decreases brevity? Is assembler more concise than a 3GL? No one creates
a DSL unless it will be used enough to justify its development, and
every time it is used it is an order of magnitude more concise than its
expansion.
Designing a good DSL is hard? Then don't do it. I doubt many people have
really created full blown languages within their applications. Instead,
a certain amount of macrology makes possible a little DSl here and a
little DSL there, spread around and swimming in the rest of the
application. That is the ultimate beauty of Lisp -- you get the benefits
of a custom language without biting the bullet of creating one as a
standalone entity.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page