Re: Why Lisp supposedly "sucks for game development"
From: Duane Rettig (duane_at_franz.com)
Date: 10/22/04
- Next message: Dirk Gerrits: "Re: Why Lisp supposedly "sucks for game development""
- Previous message: Kenny Tilton: "Re: Why Lisp supposedly "sucks for game development""
- In reply to: Cesar Rabak: "Re: Why Lisp supposedly "sucks for game development""
- Next in thread: William Bland: "Re: Why Lisp supposedly "sucks for game development""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 22 Oct 2004 01:03:31 -0700
Cesar Rabak <crabak@acm.org> writes:
> Duane Rettig escreveu:
> > Kenny Tilton <ktilton@nyc.rr.com> writes:
> [snipped]
>
> >>Feel free. <g>
> > OK. You asked for it :-)
>
> >
>
> >>I just wanted to posit a worst-case difference and make
> >>the argument that it would be irrelevant even if true.
> > But it's not irrelevant. Oh, it may be irrelevant to you,
>
> > but when you argue with a person who claims it is relevant,
> > then it becomes hard to keep from talking at cross-purposes,
> > and even harder to convincce the other person, if he is wrong,
> > that it is indeed irrelevant. Catch-22.
>
> Yes. And please folks, do not forget we normally are the novelty and
> the C (or C++) technology is the incumbent.
Interesting. Back in 1986, when I was working at Amdahl and had
just finished porting Franz Lisp (not Allegro CL) to the 370
architecture, I would spend my lunch hour at the local Togo's
reading this new book by Stroustrup describig some new language ...
> >>Except that Cesar then trumped me with the "dopey manager" card.
> > A powerful and deadly card, one not feared enough by us in the
>
> > Lisp community. You played a weak hand, when you should have
> > led with your ace.
>
> And, let me add I'm just mentioning it, I'm not hiding behind a poster ;-)
>
> Most of projects we have to justify the investments and convince
> people that cannot drill so deep in these discussions.
Yes, that tends to be the real problem in getting these projects
approved.
> [snipped]
>
> > I will never agree to the statement that "too many" are looking
>
> > into Lisp. I know that some people really do feel that way, (i.e.
> > if the unwashed masses start flocking to Lisp it will somehow
> > become diluted) but I don't believe it for a second. Lisp's
> > strengths are its own, and its weaknesses are its strengths, and
> > no deluge will change that; we will never have "too many" Lispers.
> > The fact that we still have detractors still keeps us on our toes...
>
> Perhaps '"too many" just look, but we ask then they repply 'they're
> just browsing'?!
>
>
> Also I cannot grok "...and its weaknesses are its strengths...".
Especially for Common Lisp: its greatest strength is its generality
and its versatility - this tends to also make it invisible.
What do you hear more about; systems that are well-designed and just _work_,
or systems which have fundamental design flaws and must be constantly
fixed? Which system tends to get more money spent on it (especially
money that had not been anticipated)?
> >>Maybe I should turn Cello into a games engine. I see from one of the
> >>Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
> > Hmm, indeed. And?... Do we have enough gamers in the ranks?
>
>
> I can guess we probably not, and we get another Catch-22?
Perhaps; a lack of a critical mass in a specific domain, but
people understanding what can be done and doing it can build their
ranks and reach that critical mass.
> [snipped]
>
> > The bottom line is that all languages eventually get down to the
> > hardware, and it comes down to the same transistors turning on
> > and off - they switch just as fast for one language as for another;
> > it is just a question of how many times, which is an indicator of
> > how low-level your language can go. But in this bit-Lambada [sic],
>
> More or less. The idea of an HLL is that it brings some kind of
> additional code to create the ilusion of an abstract machine which the
> bare metal does not enforce. Take, for example, dynamic typing.
Yes; any extensible language will bring that "height". The question
is whether it loses sight of its lower regions, or whether that height
can be used to in fact get back down to the low-level. At my previous
company, I was amazed to see very few labs in the hardware-design
departments; they used software almost exclusively to design, simulate,
and build their hardware. (and they put gates, logic components, and
subsystems together in software with constructs they call ... macros!
> There is a reasonable expectation that this service being provided by
> the language runtime will ask for some additional leg swing in the
> bit-Lambada (loved this one!).
Well, I have no doubts that Lisp systems won't be able to squeeze
themselves as thin as paper to get under the bar, but I also have no
doubts that Lisp systems can manufacture paper that can then be slipped
under.
> > Becase Lisp is a language generating language, though, it can breeze
> > through the entire realm; it can (and does) generate to the very bit
> > level that is executed. So, being both a high-level and a low-level
> > language, we need to honor those features of the language that allow
> > such to-the-metal grinding even though our own tendency is to run
> > away from that metal as fast as possible and layer ourselves with
> > higher-level concepts.
> > Feel free to identify or not with any portions of that last
> > paragraph.
>
>
> My only clarifying question is: can we say the above is true in
> general? Or put in other words, can it be conceived as reasonable that
> if you use non fancy (specific) Lisp implementations nor require Lisp
> gurus for programming we arrive at the results the paragraph points to?
You speak of gurus, and yet if you've done any Lisp programming at
all, you've done some of it. Have you ever created a macro? What was
it for? If it was just to hide things, or to allow less typing, then
that's not it. But if it was to congeal a concept into something that
can be thought of in a way closer to the problem your program was trying
to solve, then you took a tiny step toward domain-specific extension.
Moving the modelling back down toward the hardware takes a little more
patience, planning, and art, but it is just an extension of what you've
done.
-- Duane Rettig duane@franz.com Franz Inc. http://www.franz.com/ 555 12th St., Suite 1450 http://www.555citycenter.com/ Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
- Next message: Dirk Gerrits: "Re: Why Lisp supposedly "sucks for game development""
- Previous message: Kenny Tilton: "Re: Why Lisp supposedly "sucks for game development""
- In reply to: Cesar Rabak: "Re: Why Lisp supposedly "sucks for game development""
- Next in thread: William Bland: "Re: Why Lisp supposedly "sucks for game development""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
