·············@swipnet.se (Peter Lewerin) wrote
> There is a paradigm
> difference between CLOS and non-OOP Lisp code, but the language is the
> same, and it's quite possible to mix the two.
D'oh.
I first meant to write approximately "There is a complexity difference
[...] but no paradigm difference.", but then I thought people would
think I didn't understand the proper meaning of 'paradigm' in this
case. So I was going to write "There is a complexity difference
[...], but the language is the same, and it's quite possible to mix
the two." And then 'paradigm' slipped in where 'complexity' should
be.
My point is that CLOS code involves more components and
interconnections: it's a little bit more complicated than straight
non-OOP Lisp code. However, CLOS code is still "Lispy" all the way,
and CLOS code and non-OOP Lisp code work well together. As a simple
example, PRINT, a basic printing function in Lisp, works equally well
with CLOS objects as with non-OOP data.
C++ is a old gadget library built incrementally from the past, now there is
cleaner OO languages.
IMHO, Java is the language for games starting from now.
CPU are going faster, there is no reasons to not use Java for games.
Java is easy to debug, easy to maintain, easy to port as C++ is, etc ...
Programmers need to involve and try some other languages (not only Java).
In article <···············@uni-berlin.de>, ·········@lutin.fr says...
> C++ is a old gadget library built incrementally from the past, now there is
> cleaner OO languages.
>
> IMHO, Java is the language for games starting from now.
>
> CPU are going faster, there is no reasons to not use Java for games.
> Java is easy to debug, easy to maintain, easy to port as C++ is, etc ...
>
> Programmers need to involve and try some other languages (not only Java).
I don't see Java as having any major advantage over C++ for experienced
programmers. And it has some real disadvantages.
I wouldn't be surprised if it gets a run in massively multi-player RPGs
and the like, though. (And of cource it is popular for cellphone
games.)
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> wrote in message news:<··························@news.indigo.ie>...
> In article <···············@uni-berlin.de>, ·········@lutin.fr says...
> > C++ is a old gadget library built incrementally from the past, now there is
> > cleaner OO languages.
> >
> > IMHO, Java is the language for games starting from now.
> >
> > CPU are going faster, there is no reasons to not use Java for games.
> > Java is easy to debug, easy to maintain, easy to port as C++ is, etc ...
> >
> > Programmers need to involve and try some other languages (not only Java).
>
> I don't see Java as having any major advantage over C++ for experienced
> programmers. And it has some real disadvantages.
>
> I wouldn't be surprised if it gets a run in massively multi-player RPGs
> and the like, though. (And of cource it is popular for cellphone
> games.)
From http://www.research.att.com/~bs/applications.html:
ZeroC (http://www.zeroc.com/): Provides ICE, a distributed
object-oriented computing infrastructure with a modern C++ mapping.
ICE is written in portable C++ and compiles with a wide range of C++
compilers. ICE is used for massive multi-player games, such as Mutable
Realms' on-line multiplayer role-playing game Wish that allows tens of
thousands simultaneous players in a single game world. The game's core
logic and performance-critical functions are written in C++ using ICE.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
>
> - Gerry Quinn
Bjarne Stroustrup wrote:
> From http://www.research.att.com/~bs/applications.html:
>
> ZeroC (http://www.zeroc.com/): Provides ICE, a distributed
> object-oriented computing infrastructure with a modern C++ mapping.
> ICE is written in portable C++ and compiles with a wide range of C++
> compilers. ICE is used for massive multi-player games, such as Mutable
> Realms' on-line multiplayer role-playing game Wish that allows tens of
> thousands simultaneous players in a single game world. The game's core
> logic and performance-critical functions are written in C++ using ICE.
And just today someone at work pointed out Hello Kitty had a massively
multi-player game offering.
I asked, "So can I get into it, grab a machine gun, and hose down HK?"
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
"Vincent Cantin" <·········@lutin.fr> wrote in message news:<···············@uni-berlin.de>...
> C++ is a old gadget library built incrementally from the past, now there is
> cleaner OO languages.
C++ is NOT AN OO LANGUAGE! It supports OO programming, but offers many
more design options. If you exclusively program OO programs then use
java, or smalltalk or an OO language.
Why do people try to sew cloth with spears and kill lions with
needles?
Jeremy J.
In article <····························@posting.google.com>,
········@myrealbox.com says...
> "Vincent Cantin" <·········@lutin.fr> wrote in message news:<···············@uni-berlin.de>...
> > C++ is a old gadget library built incrementally from the past, now there is
> > cleaner OO languages.
>
> C++ is NOT AN OO LANGUAGE! It supports OO programming, but offers many
> more design options. If you exclusively program OO programs then use
> java, or smalltalk or an OO language.
That is the argument of people who want to misuse C++, and don't like to
be shown up by those using it properly! C++ was designed to be OO, with
support for exceptional cases as well as legacy C code.
> Why do people try to sew cloth with spears and kill lions with
> needles?
Whatever kills the lions gets used.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <····························@posting.google.com>,
> ········@myrealbox.com says...
> > "Vincent Cantin" <·········@lutin.fr> wrote in message
> > news:<···············@uni-berlin.de>...
> > > C++ is a old gadget library built incrementally from the past, now there
> > > is
> > > cleaner OO languages.
> >
> > C++ is NOT AN OO LANGUAGE! It supports OO programming, but offers many
> > more design options. If you exclusively program OO programs then use
> > java, or smalltalk or an OO language.
>
> That is the argument of people who want to misuse C++, and don't like to
> be shown up by those using it properly!
People like Stroustrup? See:
http://www.research.att.com/~bs/bs_faq.html#Object-Oriented-language
http://www.research.att.com/~bs/bs_faq.html#multiparadigm
http://www.research.att.com/~bs/oopsla.pdf
http://www.research.att.com/~bs/bs_faq.html#advanced
http://www.research.att.com/~bs/bs_faq.html#why
Gerry, you're not a C++ advocate, you're an OOP zealot who
happens to use C++. You use C++ in a more orthodox manner
than Stroustrup himself recommends, and you've demonstrated
a remarkable ability to disregard the new ideas you've been
shown here based on your vague impression of Lisp or Lisp
advocates.
In article <··························@news.vanderbilt.edu>,
····@vanderbilt.edu says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > > C++ is NOT AN OO LANGUAGE! It supports OO programming, but offers many
> > > more design options. If you exclusively program OO programs then use
> > > java, or smalltalk or an OO language.
> >
> > That is the argument of people who want to misuse C++, and don't like to
> > be shown up by those using it properly!
>
> People like Stroustrup? See:
>
> http://www.research.att.com/~bs/bs_faq.html#Object-Oriented-language
> http://www.research.att.com/~bs/bs_faq.html#multiparadigm
> http://www.research.att.com/~bs/oopsla.pdf
> http://www.research.att.com/~bs/bs_faq.html#advanced
> http://www.research.att.com/~bs/bs_faq.html#why
>
> Gerry, you're not a C++ advocate, you're an OOP zealot who
> happens to use C++. You use C++ in a more orthodox manner
> than Stroustrup himself recommends, and you've demonstrated
> a remarkable ability to disregard the new ideas you've been
> shown here based on your vague impression of Lisp or Lisp
> advocates.
If you read that pdf file, you'll see that Stroustrup uses the term
'multiparadigm language' when struggling for words. He wraps up by
saying: "I have argued that there are - and must be - useful techniques
beyond object-oriented programming and design. However, to avoid being
totally misunderstood, I would like to emphasise that I wouldn't attempt
a serious project using a programming language that didn't at least
support the classical notion of object-oriented programming."
I don't disagree with any of that. What I reject is the notion of those
who latch onto unfortunate terms like 'multiparadigm language', that
object orientation is just one of a number of equally useful and valid
general-purpose approaches to the programming and design of non-niche
software.
- Gerry Quinn
I suggest you think before you post, because quite frankly, you are
making a total fool of yourself.
Take a look at the publicly availiable boost libraries (www.boost.org)
for some high quality non-niche professional grade libraries that use
multi-paradigm designs to solve very difficult and complex programming
tasks. If you think that the Boost Graph Library (BGL) could be
written in a 'pure' object oriented language and be taken seriously,
then you should get your head checked.
The BGL was written at the laboratory of scientific computing of Notre
Dame. If you think that Scientific Computing is a niche market, then
you don't know someone with Cancer, or a Genetic Disorder. There is
nothing a-priori that prevents an OO language from being statically
bound, but without the C++ template meta-programming techniques used
by the library , it would (literally) be 100 TIMES SLOWER.
I don't want to wait 100 times longer for a cure for AIDS, or a clean
energy source, or to know the trajectory of an asteriod.
Nothing against OO design, but it is only ONE design solution among
MANY, and anyone who limits themselves to it will is limiting their
options for success.
Jeremy J
> If you read that pdf file, you'll see that Stroustrup uses the term
> 'multiparadigm language' when struggling for words. He wraps up by
> saying: "I have argued that there are - and must be - useful techniques
> beyond object-oriented programming and design. However, to avoid being
> totally misunderstood, I would like to emphasise that I wouldn't attempt
> a serious project using a programming language that didn't at least
> support the classical notion of object-oriented programming."
>
> I don't disagree with any of that. What I reject is the notion of those
> who latch onto unfortunate terms like 'multiparadigm language', that
> object orientation is just one of a number of equally useful and valid
> general-purpose approaches to the programming and design of non-niche
> software.
>
> - Gerry Quinn
In article <····························@posting.google.com>,
········@myrealbox.com says...
> I suggest you think before you post, because quite frankly, you are
> making a total fool of yourself.
I suggest you learn not to top post, before you start resorting to
insults because you can't face the truth about your pet language. You
could also try reading the post you respond to.
[What I said]
> > I don't disagree with any of that. What I reject is the notion of those
> > who latch onto unfortunate terms like 'multiparadigm language', that
> > object orientation is just one of a number of equally useful and valid
> > general-purpose approaches to the programming and design of non-niche
> > software.
> Take a look at the publicly availiable boost libraries (www.boost.org)
> for some high quality non-niche professional grade libraries that use
> multi-paradigm designs to solve very difficult and complex programming
> tasks. If you think that the Boost Graph Library (BGL) could be
> written in a 'pure' object oriented language and be taken seriously,
> then you should get your head checked.
I am aware of Boost, and I even mentioned an associated project
previously on this thread. On 1 Nov I said: "Spirit is part of a
library project on the STL level. My view, perhaps controversial, is
that templates are for writing libraries that will see massive re-use.
Day-to-day programming will use such libraries, but day-to-day
programming should not involve writing templates."
The same applies to Boost. Writing STL-level libraries IS a niche
software project. [Frankly, I think it attracts more people than its
usefulness deserves - it attracts people who program for programming's
sake, who believe algorithms are everything, who produce over-complex
'clever' solutions to problems that people have long learned to bypass.
A tiny fraction of Boost, including perhaps the graph library, may get
in STL eventually, and some of it will even see serious use thereafter.
But even if it sees as much general use as the important parts of STL
such as sorting and collections, it will still be niche software.]
In short, if you think I'm saying generic programming is not useful for
making STL extensions, you are misreading me. What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".
> The BGL was written at the laboratory of scientific computing of Notre
> Dame. If you think that Scientific Computing is a niche market, then
> you don't know someone with Cancer, or a Genetic Disorder. There is
> nothing a-priori that prevents an OO language from being statically
> bound, but without the C++ template meta-programming techniques used
> by the library , it would (literally) be 100 TIMES SLOWER.
> I don't want to wait 100 times longer for a cure for AIDS, or a clean
> energy source, or to know the trajectory of an asteriod.
"Software is written in a university" does not imply "this software will
cure AIDS". As for your 100X, we will discuss that another time if you
like - let me note only that the only overhead necessary for a graph
library written without generic programming is the overhead of copying
your graph into the appropriate format for the library to use - and it
might well be MORE optimised once that is done. In software, there's
always more than one way to skin a cat.
> Nothing against OO design, but it is only ONE design solution among
> MANY, and anyone who limits themselves to it will is limiting their
> options for success.
Your attitude as expressed in the first part of that sentence is exactly
what I am disagreeing with, despite the fact that the last clause is
perfectly correct. There are cases when other approaches are better,
but that does not mean the other approaches should be considered as
having equal status in general.
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> What I'm saying is that
> there are no paradigms that are "[compared to OO] equally useful and
> valid general-purpose approaches to the programming and design of non-
> niche software".
So your absolutely sure that nothing has ever or will come along that will
be better than OO (and you probably mean a particular type of OO) that will
ever be better?
I now that what your saying above is not as strong as this, but there are a
lot of paradigms developed in the last 40 years that not many people are
aware of.
Or do you mean just from paradigms that the majority of programmers know?
Why do you believe this? Or even a watered down version of this?
Why do you believe that OO can't be improved, surpassed or augmented?
What aspects of OO can't be improved upon?
In what ways is OO unsurpassable?
Rene.
In article <············@news.sap-ag.de>, ··············@hotmail.de
says...
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> ·······························@news.indigo.ie...
>
> > What I'm saying is that
> > there are no paradigms that are "[compared to OO] equally useful and
> > valid general-purpose approaches to the programming and design of non-
> > niche software".
>
> So your absolutely sure that nothing has ever or will come along that will
> be better than OO (and you probably mean a particular type of OO) that will
> ever be better?
I think anything that supersedes OO will build on OO, rather than
replace it.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <············@news.sap-ag.de>, ··············@hotmail.de
> says...
> > "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> > ·······························@news.indigo.ie...
> >
> > > What I'm saying is that
> > > there are no paradigms that are "[compared to OO] equally useful and
> > > valid general-purpose approaches to the programming and design of non-
> > > niche software".
> >
> > So your absolutely sure that nothing has ever or will come along that will
> > be better than OO (and you probably mean a particular type of OO) that will
> > ever be better?
>
> I think anything that supersedes OO will build on OO, rather than
> replace it.
Yep: http://www.tilton-technology.com/cells_top.html
(as long as we are advertising our sites. <g>)
kt
> Yep: http://www.tilton-technology.com/cells_top.html
>
> (as long as we are advertising our sites. <g>)
>
Does it still only work in ACL and Lispworks, or can I give it a try with
SBCL/Linux now?
I tried asdf-installing it, but got naught but compilation errors; that
might be a problem on my side, though, as series isn't working either.
On a sidenote, the asdf-install package didn't put anything
in .sbcl/systems, nor did it (apparently) attempt to compile it. That
should be easily fixable, I suppose.
Svein Ove Aas <·········@aas.no> writes:
> > Yep: http://www.tilton-technology.com/cells_top.html
> >
> > (as long as we are advertising our sites. <g>)
> >
>
> Does it still only work in ACL and Lispworks, or can I give it a try with
> SBCL/Linux now?
>
> I tried asdf-installing it, but got naught but compilation errors; that
> might be a problem on my side, though, as series isn't working either.
The asdf-installable version was last tested with sbcl 0.8.8 and
0.8.10 on Mac OS X and Linux/x86, so I'd expect it to work with
whatever you have. [...] I just checked with 0.8.14, and it works
here. It sounds like you have a problem with your sbcl installation.
Do note, though, that the asdf-installable Cells is Cells-1, and Cells
is currently in version 2 (in CVS). I'll probably push for a release
in either December or January.
> On a sidenote, the asdf-install package didn't put anything
> in .sbcl/systems, nor did it (apparently) attempt to compile it. That
> should be easily fixable, I suppose.
That definately tells me something is wrong on your end. I'd try
asdf-installing hello-world, and possibly following up to sbcl-help if
it doesn't work.
Thomas F. Burdick wrote:
> Svein Ove Aas <·········@aas.no> writes:
>
>> > Yep: http://www.tilton-technology.com/cells_top.html
>> >
>> > (as long as we are advertising our sites. <g>)
>> >
>>
>> Does it still only work in ACL and Lispworks, or can I give it a try with
>> SBCL/Linux now?
>>
>> I tried asdf-installing it, but got naught but compilation errors; that
>> might be a problem on my side, though, as series isn't working either.
>
> The asdf-installable version was last tested with sbcl 0.8.8 and
> 0.8.10 on Mac OS X and Linux/x86, so I'd expect it to work with
> whatever you have. [...] I just checked with 0.8.14, and it works
> here. It sounds like you have a problem with your sbcl installation.
>
> Do note, though, that the asdf-installable Cells is Cells-1, and Cells
> is currently in version 2 (in CVS). I'll probably push for a release
> in either December or January.
>
>> On a sidenote, the asdf-install package didn't put anything
>> in .sbcl/systems, nor did it (apparently) attempt to compile it. That
>> should be easily fixable, I suppose.
>
> That definately tells me something is wrong on your end. I'd try
> asdf-installing hello-world, and possibly following up to sbcl-help if
> it doesn't work.
I'm getting 404 for hello-world, but I'm not sure it's all that simple. Lots
of other packages *do* work, after all.
You're right, though, something is very wrong here.
In article <············@services.kq.no>,
Svein Ove Aas <·········@aas.no> wrote:
> Thomas F. Burdick wrote:
>
> > Svein Ove Aas <·········@aas.no> writes:
> >
> >> > Yep: http://www.tilton-technology.com/cells_top.html
> >> >
> >> > (as long as we are advertising our sites. <g>)
> >> >
> >>
> >> Does it still only work in ACL and Lispworks, or can I give it a try with
> >> SBCL/Linux now?
> >>
> >> I tried asdf-installing it, but got naught but compilation errors; that
> >> might be a problem on my side, though, as series isn't working either.
> >
> > The asdf-installable version was last tested with sbcl 0.8.8 and
> > 0.8.10 on Mac OS X and Linux/x86, so I'd expect it to work with
> > whatever you have. [...] I just checked with 0.8.14, and it works
> > here. It sounds like you have a problem with your sbcl installation.
> >
> > Do note, though, that the asdf-installable Cells is Cells-1, and Cells
> > is currently in version 2 (in CVS). I'll probably push for a release
> > in either December or January.
> >
> >> On a sidenote, the asdf-install package didn't put anything
> >> in .sbcl/systems, nor did it (apparently) attempt to compile it. That
> >> should be easily fixable, I suppose.
> >
> > That definately tells me something is wrong on your end. I'd try
> > asdf-installing hello-world, and possibly following up to sbcl-help if
> > it doesn't work.
>
> I'm getting 404 for hello-world, but I'm not sure it's all that simple. Lots
> of other packages *do* work, after all.
>
> You're right, though, something is very wrong here.
Well I just replaced the existing create-symlinks.sh with yours, so
there is another variable. :)
kt
In article <···········@services.kq.no>,
Svein Ove Aas <·········@aas.no> wrote:
> > Yep: http://www.tilton-technology.com/cells_top.html
> >
> > (as long as we are advertising our sites. <g>)
> >
>
> Does it still only work in ACL and Lispworks, or can I give it a try with
> SBCL/Linux now?
Cells per se, which is just the FRP aka constraints aka dataflow hack
runs everywhere.
The asdf-install may well be "down" as it is not maintained and things
have been moving around. The only reliable stuff is in CVS, and c-l.net
tarballs that nightly if you know your way around ViewCVS. If not I
would be happy to assist.
Cello (the ball of library mud starring OpenGL) was ported to Linux
quite a while ago by Frank Goenninger, but time has passed that by and
its resurrection must wait:
We two, we happy two, stand now just outside OS X/Cocoa in the seventh
day of a siege on that worthy foe. Several times its walls we breached,
yet brave defenders pushed us back. They have our respect, yet we will
crush them.
Gentlemen in England now a-bed who know OS X or OpenMCl or Slime are
welcome to join our band of brothers. A runner has been sent to the
Yobbos, but that was a while ago; we fear the worst.
>
> I tried asdf-installing it, but got naught but compilation errors; that
> might be a problem on my side, though, as series isn't working either.
>
>
> On a sidenote, the asdf-install package didn't put anything
> in .sbcl/systems, nor did it (apparently) attempt to compile it. That
> should be easily fixable, I suppose,
Mr. Gilham will be by shortly to assist. :)
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> Gentlemen in England now a-bed who know OS X or OpenMCl or Slime are
> welcome to join our band of brothers. A runner has been sent to the
> Yobbos, but that was a while ago; we fear the worst.
We ate him. Please send another (and less _stringy_)
-dan
--
"please make sure that the person is your friend before you confirm"
> Mr. Gilham will be by shortly to assist. :)
Sure. Where's the paper tape?
--
Fred Gilham ······@csl.sri.com
"I'm an expert at installing free software. I've installed software
packages that had 412 steps, the first two of which were 'Remove small
children and animals from the premises' and 'Don protective gloves and
mask'. If you made a mistake you had to go back to the very
beginning, including getting the kids and pets back in the house."
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> In article <············@news.sap-ag.de>, ··············@hotmail.de
> says...
> > "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> > ·······························@news.indigo.ie...
> >
> > > What I'm saying is that
> > > there are no paradigms that are "[compared to OO] equally useful and
> > > valid general-purpose approaches to the programming and design of non-
> > > niche software".
> >
> > So your absolutely sure that nothing has ever or will come along that will
> > be better than OO (and you probably mean a particular type of OO) that will
> > ever be better?
>
> I think anything that supersedes OO will build on OO, rather than
> replace it.
Amazing. In one sentence you manage to be wrong on two counts.
/Jon
>
> - Gerry Quinn
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>, ······@foo.com
says...
> Gerry Quinn <······@DELETETHISindigo.ie> writes:
>
> > > So your absolutely sure that nothing has ever or will come along that will
> > > be better than OO (and you probably mean a particular type of OO) that will
> > > ever be better?
> >
> > I think anything that supersedes OO will build on OO, rather than
> > replace it.
>
> Amazing. In one sentence you manage to be wrong on two counts.
Which are?
- Gerry Quinn
Gerry Quinn wrote:
> I don't think Lisp is going to take over from VB any time soon...
> I ask again -
> I think anything that supersedes OO will build on OO, rather than
> replace it.
Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
Idiots hits the stores. You will then be able to partake in all of the
offerings of the language. There is no need to worry your head about this
Lisp thing just yet. Until then, PLONK.
In article <··················@yahoo.com>, ··········@yahoo.com says...
>
> Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
> Idiots hits the stores. You will then be able to partake in all of the
> offerings of the language. There is no need to worry your head about this
> Lisp thing just yet. Until then, PLONK.
So, what have you achieved using Lisp? (Other than masturbatory
fantasies about controlling the Matrix.)
- Gerry Quinn
"Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
·······························@news.indigo.ie...
> In article <··················@yahoo.com>, ··········@yahoo.com says...
>>
>> Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
>> Idiots hits the stores. You will then be able to partake in all of the
>> offerings of the language. There is no need to worry your head about this
>> Lisp thing just yet. Until then, PLONK.
>
> So, what have you achieved using Lisp? (Other than masturbatory
> fantasies about controlling the Matrix.)
Seriously, Gerry... the answer is nothing. None of us has achieved anything
with Lisp. You've seen and scoffed at all the links to the measly and
pathetic accomplishments we can boast of and you have understood and seen
right through all the "emperor's clothing" -the macros, the MOP, the dynamic
types, the tack-on, clumsy excuse for object orientation we call CLOS etc.
You do not need to learn anything about Lisp.
So move on already.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> ·······························@news.indigo.ie...
>
>>In article <··················@yahoo.com>, ··········@yahoo.com says...
>>
>>>Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
>>>Idiots hits the stores. You will then be able to partake in all of the
>>>offerings of the language. There is no need to worry your head about this
>>>Lisp thing just yet. Until then, PLONK.
>>
>>So, what have you achieved using Lisp? (Other than masturbatory
>>fantasies about controlling the Matrix.)
>
>
> Seriously, Gerry... the answer is nothing. None of us has achieved anything
> with Lisp. You've seen and scoffed at all the links to the measly and
> pathetic accomplishments we can boast of and you have understood and seen
> right through all the "emperor's clothing" -the macros, the MOP, the dynamic
> types, the tack-on, clumsy excuse for object orientation we call CLOS etc.
> You do not need to learn anything about Lisp.
>
> So move on already.
>
In a game development list, it is valid to ask "what have you achieved"
and being given some game projects as an answer (Naughty Dog and Abuse
are two answers I can think of that would have done, for example).
Answering with features of the languages as achievements won't help
someone who wants to know what a language can do for them, external to
the inheirent joy of the language itself :o)
In article <·····················@news.xtra.co.nz>, ··@here.there.com
says...
> Coby Beck wrote:
> > "Gerry Quinn" <······@DELETETHISindigo.ie> wrote in message
> >>In article <··················@yahoo.com>, ··········@yahoo.com says...
> >>
> >>>Gerry Quinn, I'll be sure to let you know when Common Lisp for Complete
> >>>Idiots hits the stores. You will then be able to partake in all of the
> >>>offerings of the language. There is no need to worry your head about this
> >>>Lisp thing just yet. Until then, PLONK.
> >>
> >>So, what have you achieved using Lisp? (Other than masturbatory
> >>fantasies about controlling the Matrix.)
> >
> > Seriously, Gerry... the answer is nothing. None of us has achieved anything
> > with Lisp. You've seen and scoffed at all the links to the measly and
> > pathetic accomplishments we can boast of and you have understood and seen
> > right through all the "emperor's clothing" -the macros, the MOP, the dynamic
> > types, the tack-on, clumsy excuse for object orientation we call CLOS etc.
> > You do not need to learn anything about Lisp.
> >
> > So move on already.
> Answering with features of the languages as achievements won't help
> someone who wants to know what a language can do for them, external to
> the inheirent joy of the language itself :o)
Let me note that my post above was directed specifically at the
insulting troll with the revealing name.
- Gerry Quinn
On Tue, 30 Nov 2004 01:30:52 +1300, Peter Ashford <··@here.there.com>
wrote:
>
> Answering with features of the languages as achievements won't help
> someone who wants to know what a language can do for them, external to
> the inheirent joy of the language itself :o)
Don't as what has been done in the language.
Ask 'what can the language do for you?'
http//www.gigamonkeys.com/book might give you some clues.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> On Tue, 30 Nov 2004 01:30:52 +1300, Peter Ashford <··@here.there.com>
> wrote:
>
>>
>> Answering with features of the languages as achievements won't help
>> someone who wants to know what a language can do for them, external
>> to the inheirent joy of the language itself :o)
>
> Don't as what has been done in the language. Ask 'what can the
> language do for you?' http//www.gigamonkeys.com/book might give you
> some clues.
And note that all the code in that book (spam filter, ID3 parser,
Shoutcast server, and more) was written by one programmer at the same
time as he was writing the book itself. Total time spent on all the
code was maybe about two months. In the meantime he also wrote code to
generate the web site, including the PDFs and the figures used in the
book[1] in Common Lisp.
-Peter
[1] Thanks to Marc Battyani's excellent cl-typesitting and cl-pdf libraries.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Mon, 29 Nov 2004 18:01:37 GMT, Peter Seibel <·····@javamonkey.com> wrote:
> In the meantime he also wrote code to generate the web site,
> including the PDFs and the figures used in the book[1] in Common
> Lisp.
BTW, Peter, have you considered publishing the PDF-generating code
somewhere, maybe as an appendix to your book? I think it could serve
as a good introduction/tutorial to CL-PDF and CL-TYPESETTING.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 29 Nov 2004 18:01:37 GMT, Peter Seibel <·····@javamonkey.com> wrote:
>
>> In the meantime he also wrote code to generate the web site,
>> including the PDFs and the figures used in the book[1] in Common
>> Lisp.
>
> BTW, Peter, have you considered publishing the PDF-generating code
> somewhere, maybe as an appendix to your book? I think it could serve
> as a good introduction/tutorial to CL-PDF and CL-TYPESETTING.
Yes. After my final drafts of the book proper go off to the printer,
I'm going to turn my attention to preparing the web site for all the
code from the book. And along with the code of the practicals I plan
to publish a version of all the code I used while writing the book.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In short, if you think I'm saying generic programming is not useful for
> making STL extensions, you are misreading me. What I'm saying is that
> there are no paradigms that are "[compared to OO] equally useful and
> valid general-purpose approaches to the programming and design of non-
> niche software".
http://www.sgi.com/tech/stl/drdobbs-interview.html
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > In short, if you think I'm saying generic programming is not useful for
> > making STL extensions, you are misreading me. What I'm saying is that
> > there are no paradigms that are "[compared to OO] equally useful and
> > valid general-purpose approaches to the programming and design of non-
> > niche software".
Functional reactive programming is the silver bullet OO wanted to be
(and it even makes OO better):
http://www.haskell.org/frp/
http://www-sop.inria.fr/meije/esterel/esterel-eng.html
http://www.tilton-technology.com/cells_top.html
:)
kenny
In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> >
> > > In short, if you think I'm saying generic programming is not useful for
> > > making STL extensions, you are misreading me. What I'm saying is that
> > > there are no paradigms that are "[compared to OO] equally useful and
> > > valid general-purpose approaches to the programming and design of non-
> > > niche software".
>
> Functional reactive programming is the silver bullet OO wanted to be
> (and it even makes OO better):
>
> http://www.haskell.org/frp/
> http://www-sop.inria.fr/meije/esterel/esterel-eng.html
> http://www.tilton-technology.com/cells_top.html
I hope your work on frp proves useful. But I'll believe it's the silver
bullet when I see it...
- Gerry Quinn
On Thu, 11 Nov 2004, Gerry Quinn wrote:
> In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> > > In article <··························@news.indigo.ie>,
> > > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > >
> > > > In short, if you think I'm saying generic programming is not useful for
> > > > making STL extensions, you are misreading me. What I'm saying is that
> > > > there are no paradigms that are "[compared to OO] equally useful and
> > > > valid general-purpose approaches to the programming and design of non-
> > > > niche software".
> >
> > Functional reactive programming is the silver bullet OO wanted to be
> > (and it even makes OO better):
> >
> > http://www.haskell.org/frp/
> > http://www-sop.inria.fr/meije/esterel/esterel-eng.html
> > http://www.tilton-technology.com/cells_top.html
>
> I hope your work on frp proves useful. But I'll believe it's the silver
> bullet when I see it...
>
I've seen a number of indications that it may well be - one of my "when I
get round to it" projects is to hook yampa (an FRP lib) up to some SDL and
OGL bindings and knock up a simple game engine. That said, it would still
frequently help in an FRP situation to have some of the features more
commonly found in OO type systems.
You might find a paper called "The Yampa Arcade" interesting though - some
of it does look a little like reinventing OO, and I've said as much to one
of the authors, but the rest is seriously nice.
I think you're right, OO will be incorporated into the Next Big Thing.
Where we differ is that I got fed up with OO a while back and started
looking for it :-)
--
······@flippac.org
In article <·······························@SLINKY>, ······@flippac.org
says...
> You might find a paper called "The Yampa Arcade" interesting though - some
> of it does look a little like reinventing OO, and I've said as much to one
> of the authors, but the rest is seriously nice.
A signal is a function from time to a value... signals were given
names... I can see where you might have gotten that impression!
And after writing the above I read on a little to find "signals
accumulate internal state"...
Was it a good game?
- Gerry Quinn
On Fri, 12 Nov 2004, Gerry Quinn wrote:
> In article <·······························@SLINKY>, ······@flippac.org
> says...
>
> > You might find a paper called "The Yampa Arcade" interesting though - some
> > of it does look a little like reinventing OO, and I've said as much to one
> > of the authors, but the rest is seriously nice.
>
> A signal is a function from time to a value... signals were given
> names... I can see where you might have gotten that impression!
>
> And after writing the above I read on a little to find "signals
> accumulate internal state"...
>
Now take a look at things like how the physics code is written, and how
the system deals with new entities or entities changing their paths.
That's the bit that's nice IMO - the rest's theoretical framework showing
how this all works.
The accumulation of state is done in a somewhat ugly way at present (the
bit that looks like reinventing OO badly), and I can understand some
skepticism about how well things scale. One of the reasons I'd like to
play around myself is that I think I know how to go about it in Haskell
with GHC's extended featureset (much of which is supported elsewhere),
though I won't know for certain until I've hacked it up. It should be
noted that if it's a problem this has more to do with the shortcomings of
Haskell's type system than it does FRP - in fact, it occurs to me that a
good environment for FRP might actually be a language like Smalltalk.
> Was it a good game?
>
The game itself was YA simple 2D shooter, as the whole thing was an
academic exercise (I saw the mailing list posting referred to at the start
of the paper). Of course, there's no reason the game couldn't be polished
further.
--
······@flippac.org
In article <·······························@SLINKY>, ······@flippac.org
says...
> On Fri, 12 Nov 2004, Gerry Quinn wrote:
["The Yampa Arcade"]
>
> Now take a look at things like how the physics code is written, and how
> the system deals with new entities or entities changing their paths.
> That's the bit that's nice IMO - the rest's theoretical framework showing
> how this all works.
To be honest, I don't see a win over an object-oriented system.
Obviously Haskell gives you nice functions if you want to put in a lot
of physics, but one could do it in other ways. (Game physics often owes
more to Aristotle than to Newton anyway.)
In their conclusions they do mention problems with event ordering and
mutually recursive effects in OO systems, which is fair enough - but
reading on it's clear that in Yampa singularities tend to appear instead
in the same situations! Which is better, quirky object behaviour -
which is often fun - or a complete crash? I suppose it could be argued
that at least the crash will force you to fix it - but when you unbind
some of the recursive effects, your physics will also depart from
rigour.
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp02-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> > > In article <··························@news.indigo.ie>,
> > > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > >
> > > > In short, if you think I'm saying generic programming is not useful for
> > > > making STL extensions, you are misreading me. What I'm saying is that
> > > > there are no paradigms that are "[compared to OO] equally useful and
> > > > valid general-purpose approaches to the programming and design of non-
> > > > niche software".
> >
> > Functional reactive programming is the silver bullet OO wanted to be
> > (and it even makes OO better):
> >
> > http://www.haskell.org/frp/
> > http://www-sop.inria.fr/meije/esterel/esterel-eng.html
> > http://www.tilton-technology.com/cells_top.html
>
> I hope your work on frp proves useful.
Thx. But it already has! Have you been to my sight and seen what I have
done with it, yes? These are /all/ Cells-driven (in all respects, GUI as
well as abstract model and in the business app even the database, which
is persistent CLOS:
http://www.tilton-technology.com/cellophane.html
> But I'll believe it's the silver
> bullet when I see it...
Thx. But I think you will not believe it until you download it (and the
AllegroCL Trial Edition and Peter's book).
http://www.tilton-technology.com/cells_top.html
http://www.franz.com/products/
http://www.gigamonkeys.com/book/
kenny
In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
·······@nyc.rr.com says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> > I hope your work on frp proves useful.
>
> Thx. But it already has! Have you been to my sight and seen what I have
> done with it, yes? These are /all/ Cells-driven (in all respects, GUI as
> well as abstract model and in the business app even the database, which
> is persistent CLOS:
>
> http://www.tilton-technology.com/cellophane.html
Your 'cells' concept looks interesting, though it would tend to go on my
list of "interesting architecture idea" rather than "reason to change
language".
Am I right in thinking that their main function is to bring functional
programming into realms where objects currently stand supreme?
- Gerry Quinn
In article <··························@news.indigo.ie>,
Gerry Quinn <······@DELETETHISindigo.ie> wrote:
> In article <·····························@nyctyp01-ge0.rdc-nyc.rr.com>,
> ·······@nyc.rr.com says...
> > In article <··························@news.indigo.ie>,
> > Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > > I hope your work on frp proves useful.
> >
> > Thx. But it already has! Have you been to my sight and seen what I have
> > done with it, yes? These are /all/ Cells-driven (in all respects, GUI as
> > well as abstract model and in the business app even the database, which
> > is persistent CLOS:
> >
> > http://www.tilton-technology.com/cellophane.html
>
> Your 'cells' concept looks interesting, though it would tend to go on my
> list of "interesting architecture idea" rather than "reason to change
> language".
>
> Am I right in thinking that their main function is to bring functional
> programming into realms where objects currently stand supreme?
>
> - Gerry Quinn
>
That is a good way of putting it, at a low level of abstraction. ie,
yes, we now have functional slots (data members?) on instances.
At a higher level of abstraction a dataflow paradigm emerges, and the
long-lived state used to model an application acts like a spreadsheet.
Great fun, btw. And it is not just a curiosity. Lots of folks have done
things like this, and everyone who does or uses them loves the power.
Btw, I once did a proof-of-concept port of a small part of the
functionality in C++ (and Java and Python).
kt
In article <··························@news.vanderbilt.edu>,
····@vanderbilt.edu says...
> In article <··························@news.indigo.ie>,
> Gerry Quinn <······@DELETETHISindigo.ie> wrote:
>
> > In short, if you think I'm saying generic programming is not useful for
> > making STL extensions, you are misreading me. What I'm saying is that
> > there are no paradigms that are "[compared to OO] equally useful and
> > valid general-purpose approaches to the programming and design of non-
> > niche software".
>
> http://www.sgi.com/tech/stl/drdobbs-interview.html
That was 1995, and he hoped to find such a paradigm. Did he?
- Gerry Quinn
In article <····························@posting.google.com>,
········@myrealbox.com says...
> > I am aware of Boost, and I even mentioned an associated project
> > previously on this thread. On 1 Nov I said: "Spirit is part of a
> > library project on the STL level. My view, perhaps controversial, is
> > that templates are for writing libraries that will see massive re-use.
> > Day-to-day programming will use such libraries, but day-to-day
> > programming should not involve writing templates."
>
> I don't see why not. Perhaps they are too complex? Most applications
> of templates are rather simple and well defined. No doubt C++ meta
> programming requires great care (mostly because of poor compiler
> support), but if you want/need compile time resolution, I see few
> other options in the programming world.
I simply think that because of the complexity and obscurity of such
code, the win from templates only kicks in when massive reuse is
expected, and that would rarely apply at an individual project level.
> > In short, if you think I'm saying generic programming is not useful for
> > making STL extensions, you are misreading me. What I'm saying is that
> > there are no paradigms that are "[compared to OO] equally useful and
> > valid general-purpose approaches to the programming and design of non-
> > niche software".
>
> I am beginning to see what you think is niche software. I disagree.
Well, that is a matter of words.
> > "Software is written in a university" does not imply "this software will
> > cure AIDS". As for your 100X, we will discuss that another time if you
> > like - let me note only that the only overhead necessary for a graph
> > library written without generic programming is the overhead of copying
> > your graph into the appropriate format for the library to use - and it
> > might well be MORE optimised once that is done. In software, there's
> > always more than one way to skin a cat.
>
> That 100 x is compared to dynamic runtime methods, and if you think
> that converting 500 gigs or more of data to an appropriate format is
> easy buisiness, then you are mistaken. Remember that you may be forced
> to convert data for each library that you use. There can be huge
> performance losses if you want to make use of one algorithm and have
> to convert all your data there and back.
Converting a graph with 500GB of graph node data to another format might
take some time, but on the other hand I would not be expecting the
functions of Boost Graph Library to be returning anytime soon from
operations on such a graph ;-)
> > Your attitude as expressed in the first part of that sentence is exactly
> > what I am disagreeing with, despite the fact that the last clause is
> > perfectly correct. There are cases when other approaches are better,
> > but that does not mean the other approaches should be considered as
> > having equal status in general.
>
> I am not sure what you mean by "equal status". In general most
> problems will be solved well with OO principles. But by skewing your
> perspective to automatically assume that OO is the best design
> a-priori, then you miss out on many other opportunities. If two or
> more design methodologies seem equaly applicable to a design problem,
> I would choose OO because it is well understood, and well supported.
> But often design methedologies are not equaly applicable, and I have
> the sense to recognize when OO would be an inferior (or superior)
> design option.
>
> If you are saying that OO is the dominant and best understood design
> methedology today, you are correct. If you mean that trying to
> retrofit clever designs onto problems that would best be solved with
> simple, well defined OO design is stupid, then there is no
> disagreement. But where we diverge is that you beleive that OO design
> suits all non-niche projects. Since niche has not really been defined,
> we will have to agree to disagree. I personally see scientific
> computing as very mainstream, and deserves more attention to design
> issues than games or web browsers.
>
> I don't think you are wrong Gerry, I just think you are 'blinded by
> the light' and take your OO advocacy so far that you fail to see there
> are other ways to write successful (non-niche) software.
I think perhaps we are not as far apart on the spectrum as we appear,
albeit we are not in the same place either...
- Gerry Quinn
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> the win from templates only kicks in when massive reuse is expected
I find that writing template code is often easier. Push the type
concerns onto your callers. Plenty of functions or classes make
perfect sense to write without concern for the specific types they
operate on. Having to choose a type to inject into that function adds
complexity by mixing what are often orthogonal concerns. Concepts and
operations are more important than types, and templates allow us to
take advantage of that distinction.
--
Steven E. Harris
Gerry Quinn wrote:
> In article <····························@posting.google.com>,
> ········@myrealbox.com says...
>
>>>I am aware of Boost, and I even mentioned an associated project
>>>previously on this thread. On 1 Nov I said: "Spirit is part of a
>>>library project on the STL level. My view, perhaps controversial, is
>>>that templates are for writing libraries that will see massive re-use.
>>>Day-to-day programming will use such libraries, but day-to-day
>>>programming should not involve writing templates."
>>
>>I don't see why not. Perhaps they are too complex? Most applications
>>of templates are rather simple and well defined. No doubt C++ meta
>>programming requires great care (mostly because of poor compiler
>>support), but if you want/need compile time resolution, I see few
>>other options in the programming world.
>
>
> I simply think that because of the complexity and obscurity of such
> code, the win from templates only kicks in when massive reuse is
> expected, and that would rarely apply at an individual project level.
>
I don't quite buy this argument, because of experience. I don't dislike
C++, and I've worked in it quite a bit for a long time (for example, I'm
one of the implementors of the QuickTime Movie Player, which is written
in C++).
However, I'm suspicious of templates; not that they are intrinsically
bad, just that you have to think through their uses rather carefully to
avoid hurting yourself. In a recent large commercial product with which
I'm associated, the decision was made to retroactively strip out all
uses of templates because it turned out to be too easy to produce
unanticipated memory and performance problems, and too difficult to
predict them. This rather expensive decision was made by a very smart
and commercially successful group of programmers, some of whom have
produced some other familiar technologies; it's not an ignorant whim.
As I said, I don't dislike C++, but I also don't love it. I do love
Lisp. There used to be a common saying about C that these days seems to
be true of C++, at least among the experienced programmers with whom
I've worked: it's no one's favorite language, but it's everyone's second
choice, and that's why it gets used.
Gerry Quinn <······@DELETETHISindigo.ie> writes:
> C++ was designed to be OO, with
> support for exceptional cases as well as legacy C code.
It may have been designed that way, but it failed
miserably. At least according to Alan Kay.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>